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Sobre a autora 


Julia Naomi Boeira é desenvolvedora de software na ThoughtWorks 
Brasil e possui grande experiência no desenvolvimento de games. 
Ela já trabalhou com diversas engines, como Unreal, Cry, Unity, 
GameMaker Studio e com frameworks como MonoGame e 
PyGame. 


Ao utilizar PyGame e Panda3D, Julia percebeu a necessidade e a 
possibilidade de usar TDD para games. Deste momento em diante, 
ela assumiu a responsabilidade de promover essa ideia entre outras 
pessoas desenvolvedoras de games. 


Para este projeto, Julia contou com a ajuda de uma colega, Victoria 
Fuenmayor. 


Para quem é este livro 


Por muito tempo, a indústria de games foi resistente a metodologias 
ágeis. Entretanto, essa resistência decorria de tentativas frustradas 
de introduzir os frameworks ágeis em seu cotidiano, seja porque as 
pessoas não tentaram adaptá-los aos seus mundos, seja porque 
tentaram introduzir um framework específico como solução, "O 
Verdadeiro Ágil". Muitas interpretaram e consideraram um livro ou 
um processo como mais importante que o próprio manifesto ágil. 
(http://agilemanifesto.org/iso/ptbr/manifesto.html). 


Vamos lembrar dos conceitos do manifesto: 


e Indivíduos e interações mais que processos e ferramentas. 

e Software em funcionamento mais que documentação 
abrangente. 

e Colaboração com o cliente mais que negociação de contratos. 

e Responder às mudanças mais que seguir um plano. 


O que me parece um dos erros mais comuns é o peso da inversão 
causada pela primeira frase do manifesto, já que o nosso 
desenvolvimento de games, nos últimos anos, tem sido "processos 
e ferramentas acima de indivíduos e interações". Mais que isso, a 
indústria de games toma processos, ferramentas e frameworks de 
forma bastante rígida e inflexível — uma grande tristeza por esta ser 
uma indústria tão dinâmica. 


Além disso, vejo o Test-Driven Development (TDD) ou, em 
português, desenvolvimento guiado a testes, como uma 
manifestação da segunda frase do manifesto. Isso, porque creio que 
um código bem testado pode ser visto como uma forma de 
documentar e garantir a qualidade do software. Outro ponto é que 
acredito que a colaboração com o cliente é fundamental na indústria 
de jogos, especialmente pelo fato de jogos serem softwares de 
entretenimento. Por último, é um mercado que exige muita 
mudança, principalmente devido ao fato de suas tendências 
mudarem todos os dias, tornando o Lean uma ótima solução. 


Gostaria de recomendar uma breve leitura no blog de engenharia da 
Riot, que tenta aplicar muitos destes padrões. 
(https://engineering.riotgames.com/). Mais referências na 
bibliografia. 


Tendo dito isso, acredito que este livro é para todos os públicos: 
para a profissional, que gostaria de melhorar suas habilidades de 
codar com qualidade e segurança, e também para a iniciante, que 
tem como objetivo fazer seu primeiro jogo. Certamente, este livro 
não exige que você seja uma profissional no desenvolvimento de 
games, mas ter uma noção minima de C#, Java, Python, C++, Ruby 
ou qualquer outra linguagem fará com que você flua mais facilmente 
pelo livro. Um outro ponto é que é um grande prazer para mim poder 
falar de desenvolvimento de games com Programação Funcional, 
mas como os projetos que conheço ainda não são estáveis, vou 
deixá-los como referências somente para apresentar e atiçar a sua 
curiosidade: https://github.com/oakes/play-clj/ e https://arcadia- 
unity.github.io/. 


Este livro é focado na parte de desenvolvimento de software do 
jogo, por isso a obra não trata de arte, nem foca muito em conceitos 
básicos da área de jogos, como O que é um jogo? e Como um 
jogo funciona?. Não acredito que o objetivo deste livro seja ensinar 
programação à leitora, mas sim, ensinar TDD. Mesmo assim, 
exemplifiquei tudo o que fiz para ficar o mais claro possível. 


Eu decidi fazer este livro com MonoGame porque ele é de fácil 
utilização, versatilidade e bastante aceito. Além disso, gostaria de 
mencionar que, na minha opinião, a Unity é a única engine com um 
framework de testes decente, mas infelizmente ela muda 
drasticamente de uma versão para a outra. Considerando estes 
fatores de Unity e MonoGame, optei por utilizar C#, uma linguagem 
utilizada por uma grande comunidade gamer, com tutoriais extensos 
e muitos livros sobre games. 


Por último, mas não menos importante, está o fato de que times que 
desenvolvem games com o pensamento das metodologias ágeis 


necessitam que toda a equipe entenda tal pensamento. Assim, 
acredito que este livro pode ser muito útil para nivelar a equipe. Mais 
informações sobre as ideias apresentadas aqui podem ser 
encontradas no livro Lean Game Development: Desenvolvimento 
enxuto de jogos (https://www.casadocodigo.com.br/products/livro- 
lean-game-development). 


Como este livro é organizado 


Este livro está organizado em três seções. A primeira é sobre TDD e 
como ele funciona, conceitos de entrega e de integração contínuas, 
sobre como construir e fazer o design de software do seu jogo e, por 
ultimo, quais ferramentas são melhores para sua estratégia de teste. 
O que me faz lembrar que, além de ser arte, jogos também são 
softwares, um tipo específico de software que exige uma grande 
habilidade de codificação. É por isso mesmo que temos as engines, 
pois elas nos poupam tempo e linhas de código. 


A segunda seção do livro traz o desenvolvimento de um jogo da 
velha com o framework MonoGame em um Mac OS, mas as 
práticas podem ser aplicadas para qualquer sistema operacional. 
Algumas práticas de TDD serão aplicadas ao processo de 
desenvolvimento, fora do loop update/Draw , com o repositório 
completo disponível no GitHub, livre para forks e pull requests. Essa 
seção será desenvolvida com Cf, e algum conhecimento de 
Orientação a Objetos será util. 


A terceira parte tem como ideia aplicar os conceitos que 
aprendemos na segunda seção em um cenário mais real utilizando 
Unity, C#, NUnit e NSubstitute. Além disso, criamos um jogo que 
pode ser jogado por qualquer pessoa. 


Espero que todas vocês tenham uma ótima leitura deste livro e que 
possam começar a aplicar técnicas de TDD em seus projetos. 


Sugiro também que vocês deem uma olhada em outros 
frameworks e engines e em como aplicar técnicas de TDD em 


seus projetos. Alguns exemplos, para os quais as técnicas de 
TDD podem ser aplicadas são: Amethyst, Panda3D, Pygame, 
Raylib, CRYENGINE, Piston, LÓVE, ggez e Unity. 





Como e por quê? 


CAPÍTULO 1 
O que deu errado? 


Infelizmente, as pessoas desenvolveram um conceito de que 
metodologias pesadas e rígidas eram mais seguras para o 
desenvolvimento de projetos. Entretanto, sabemos que ninguém 
gosta de milhões de regras e conceitos rígidos que precisam ser 
relembrados a cada instante. Ninguém pode jogar bem em 
circunstâncias assim, e o mesmo vale para o desenvolvimento de 
games: precisa ser fluido e leve. Quando estamos trabalhando, 
queremos estar tranquilas e nos divertir, pois estes são os 
momentos em que atingimos nossos picos de criatividade e, para 
isso, é preciso muita cooperação. 


Tendo dito isso, devemos evitar ambientes muito hierárquicos e 
controladores, que tenham muitas regras e objetivos nebulosos. 
Então, o que estamos procurando”? Ambientes criativos e 
cooperativos, com metodologias, processos e ferramentas que 
possam variar, além do empoderamento da equipe em ambientes 
não hierárquicos. Desenvolvimento de games exige trabalho duro 
com muita cooperação entre equipes, o que pode ser muito 
estressante. Em um cenário desses, gerentes de projetos e 
produtores não devem estar acima da equipe. Eles são líderes e 
não chefes. Documentação excessiva é um método bastante 
utilizado pela gerência de se ver o desenvolvimento, mas não 
permite muitas chances de melhoria. Devemos desenvolver de 
modo que a documentação seja gerada a partir do desenvolvimento 
do código de forma fluida e rápida, por exemplo, com testes. Isso 
permite uma documentação mais abrangente e alivia a pressão 
sobre o time. 


Então, aqui estão algumas coisas que vi e ouvi sobre metodologias 
ágeis na indústria de games: 


"Automação de testes é mais difícil que em outras indústrias”. 
Mais difícil não significa impossível. 

"Visual nao pode ser automatizado com testes". Acredito que a 
maioria das analistas de UX vai discordar disso. 

"Crianças são a forma mais eficiente de testar games". Não 
consigo nem começar a explicar quão errado é isso. 

"O modelo do setor é maluco e guiado a jogos prontos para 
jogar". Sim! Exatamente por isso que devemos utilizar 
metodologias ágeis e Lean. 

"Eu não gosto de Scrum", como se Scrum fosse a única 
metodologia ágil. Eu também não sou fã de Scrum. 
"Sequéncias de jogos não são iterações”. Mas elas deveriam 
gerar conhecimento e não retrabalho. 

"Arte não pode ser iterada". Acredito que Jeff Patton não 
concorda, vide imagem a seguir. 

"Jogos são desenvolvidos para que usuários passem mais 
tempo jogando e não para que poupem tempo jogando”. E que 
tal a experiência de desenvolvedora? 

"Games não são testáveis". Por favor, leia este livro até o fim. 
"Entrega contínua não é atrativa para a indústria". Quem sabe 
repensamos isso? 


lterativo 

















Figura 1.1: Jeff Patton: iterações sobre a Arte 





Esse é o nosso primeiro passo para pensar o desenvolvimento de 
jogos. Vamos ao TDD. 


CAPÍTULO 2 
Introdução 


Para entender TDD precisamos entender os conceitos básicos de 
testar para codar. OK, mas o que isso significa? Basicamente, 
significa que precisamos ter uma perspectiva do que queremos 
antes de começar a implementar o jogo, de forma que saibamos 
quais testes podem ser aplicados e como iterar sobre eles para 
desenvolver o jogo. 


Entretanto, isso não é tudo. Ainda precisamos que nossos testes 
sejam significativos e que melhorem nosso código. Por isso, 
simplesmente escrever um teste que passe não demonstra nenhum 
avanço em nosso código. Um teste, para ser significativo, tem que 
quebrar o fluxo atual, ou seja, falhar. E as mudanças que 
implementarmos para ele devem ser as mínimas possíveis para que 
o teste que está falhando passe. 


Existe uma imagem conhecida do ciclo do TDD, que apresento a 
seguir. Retirei esta imagem do site: 
https://businessanalystlearnings.com/technology- 
matters/2014/8/13/test-driven-vs-behaviour-driven-development/: 


1. Escreva um bom teste 
que falhe 





Refatore 


e 2. Escreva o mínimo de código 
J. Elimine que passe o teste 
redundancia (sem quebrar os outros testes) 


Figura 2.1: O Ciclo do TDD 


Para entendermos melhor esta imagem, vamos nos debruçar sobre 
o processo do TDD: 


1. Primeiro, precisamos entender nossos casos de teste e o 
que/como queremos testar. 

2. Agora precisamos escrever o teste mais simples possível para 
que ele dê valor à nossa unidade. Para ele dar valor à unidade, 
ele deve falhar. 

3. Um teste que falha não deveria ser aceito, por isso agora temos 
que fazê-lo passar. Para isso, devemos escrever o mínimo de 
código possível, nos assegurando de que nenhum outro teste 
falhe. 

4. Agora podemos dar uma revisada no nosso código e garantir 
que não existam code smells, redundância ou coisas que 


podemos eliminar. Fazer isso também significa que nossos 
testes devem continuar passando. 

5. Na próxima iteração devemos voltar ao passo 2 até que não 
existam mais casos de teste. Sempre lembrando de que código 
novo não pode quebrar testes antigos. 

6. Por último, todos os nossos cenários de testes estão prontos e 
podemos checar se a integração e a funcionalidade do código 
estão OK. 

7. Volte ao passo 1 para outros testes. 


QUANDO REFATORAR? 


e Quando você tem código duplicado. 


e Quando vemos que o código não é claro ou legível. 
e Quando detectamos um código potencialmente perigoso. 





O que é TDD? 
Definição: 


TDD (Test-Driven Development, é uma prática de desenvolvimento 
de software apresentada por Kent Beck junto com a metodologia de 
eXtreme Programming (XP). Ela se baseia em desenvolver um 
sistema a partir de seus casos de teste. É escrever tais casos e, 
consequentemente, os próprios testes, de forma que uma 
funcionalidade seja implementada a partir da demanda de cada 
teste. A solução é implementada logo depois que cada teste é 
escrito, e um teste é implementado por vez, transformando em um 
ciclo contínuo de testar e codar. 


Características 


Esse método de desenvolvimento de software possui as seguintes 
características: 


e Um conjunto de testes escritos pela pessoa que desenvolveu o 
código. 

e Nenhum código é escrito sem ser testado (prática de testar 
primeiro). 

e O código é o mais simples possível. 


Algumas recomendações importantes do TDD são: 


1. Corra os testes frequentemente, isso permite que as pessoas 
desenvolvedoras visualizem o estado geral do seu código. 

2. Mantenha todo código testado especialmente nas menores 
unidades. Quanto mais simples e unitário o código for, mais fácil 
será de corrigir um build quebrado. 

3. Trate testes que falham como builds que falham. Algumas 
pessoas fazem revert do código e começam de novo. Builds 
que falham podem levar bugs à produção e devem ser 
considerados de suma importância. O mesmo vale para testes, 
se a lógica que foi implementada no teste faz ele ou outro 
falhar, o melhor seria começar de novo. 

4. Mantenham os testes simples, pois testes complexos talvez 
não estejam testando as unidades desejadas. 

5. Testes devem ser independentes uns dos outros, porque 
eles devem testar unidades, funcionalidades ou componentes 
específicos. 


Algumas das vantagens do TDD são: 


e O código se torna mais compreensível e manutenível. 
e Soluções mais simples são permitidas. 

e A quantidade de defeitos é menor. 

e A quantidade de bugs é menor. 

e Documentação extensiva. 

e Design elegante do código. 


2.1 Por que temos tantos códigos mal testados? 


Você usaria um colete à prova de balas que não foi testado? Vejo o 
desenvolvimento de software da mesma maneira. Deixe-me contar 
um segredo. Alguns anos atrás eu não gostava de TDD, de testes 
unitários e de muitos tipos de testes que eu, como desenvolvedora, 
precisava escrever. Eu testava majoritariamente estados locais ou 
globais com writeLine OU Printin , e hoje estou aqui evangelizando 
o uso do TDD. Por que isso aconteceu? 


Na minha carreira de desenvolvimento de jogos, escrevi muitas 
linhas de código com quase nenhum teste. E qual foi meu 
resultado”? Tive de reescrever a maior parte em algum momento, às 
vezes devido a falhas em testes manuais e outras devido a códigos 
tão complexos, que eram ilegíveis. Isso se tornou um problema 
menos frequente a partir do momento em que adotei o TDD. Claro 
que eu levava um pouco mais de tempo para escrever meus 
códigos, mas em geral não havia necessidade de retrabalho e era 
possível entregar mais valor com meu código. 


Além disso, percebi alguns motivos pelos quais os testes eram 
desenvolvidos de forma tão ruim na indústria de software: 


e Se testes não são facilmente compreensíveis, bugs podem ser 
colocados em produção gerando efeitos catastróficos. 

e Testes são geralmente escritos depois do código, o que é um 
problema, porque sua mente já terminou o trabalho e não quer 
voltar ao início para pensar em tudo o que foi feito. 

e Geralmente, os testes são escritos por pessoas diferentes das 
pessoas que desenvolveram o código. Como elas talvez não 
entendam completamente a ideia por trás do código, é possível 
que elas abordem os testes de uma maneira equivocada. 

e Se a pessoa que escreve testes o faz com base em 
documentação ou artefatos, qualquer upgrade pode tornar os 
testes obsoletos. 

e Testes não automatizados não serão executados 
frequentemente e, provavelmente, não rodarão da mesma 
forma sempre. 


e "Corrigir" um problema em um lugar pode causar outro 
problema em outro lugar. Cobertura de testes lhe garante que 
isso não acontecerá. Além disso, é muito mais fácil identificar 
de onde veio o problema. 


TDD resolves todos estes dramas! 


e À pessoa desenvolve os testes antes de codar, o que permite 
testabilidade e cobertura de testes. 

e Isso facilita rodar testes de forma automatizada e mais 
frequente. 

e Permite que bugs sejam corrigidos rapidamente e 
pontualmente, procedimento garantido pela cobertura de testes. 

e Quando o código é entregue, os testes são entregues junto, o 
que facilita mudanças futuras. 


Como isso pode se relacionar com jogos? 


Podemos usar o trabalho de Rob Galanakis (2014) para revelar o 
mindset antiagile da indústria de games. O nome do artigo é Agile 
Game Development is Hard, ou "Desenvolvimento ágil de jogos é 
difícil", e ele parece bastante recente para mim, mesmo que 
atualmente as coisas tenham melhorado, vide lista no final do 
capítulo anterior. 


Para saber mais 


Algumas dicas de vídeos para assistir sobre o início da mentalidade 
de testes na Unity: 


e Unity. Unite Boston 2015 - Unity Test Tools: Automação de 
testes na Unity agora e no futuro (em inglés). 2015.Disponivel 
em: https://youtu.be/wJGUc-EeK yw. 

e Unity. Unity Test Tools: Automação de testes na Unity agora e 
no futuro - Unite Europe 2015 (em inglês). 2015. Disponível em: 
https://youtu.be/ OYojVTagxY. 


CAPÍTULO 3 
O mundo do Build e do Design 


Antes de codar, precisamos entender o jogo, ter a imagem 
completa. Isso nos permitirá começar a testar e então escrever o 
código. Em um ambiente de desenvolvimento Lean, nós deveríamos 
iniciar gerando hipóteses, com elas, planejar o design do jogo e, 
com o design em mãos, planejar os passos que vamos construir. É 
importante lembrar que o design e o build devem ser facilmente 
modificáveis e que iterar sobre eles para poder evoluir seus 
conceitos é algo necessário. Isso nos permite evitar que jogos ruins 
cheguem ao mercado e previne também bugs em produção e 
clientes insatisfeitas. 


Em termos gerais, o design é responsável pelo visual, pela 
expressão artística dos jogos e também pela experiência do usuário. 
Basicamente se refere ao "o quê". Por outro lado, o build se refere 
ao "como". Ele é responsável pela pré-visualização, caso o design 
seja viável, e, além disso, é responsável pelas ferramentas que 
tornam este design possível. Em outras palavras: o design produz a 
receita e o build produz o jantar. Então, design é sobre utilidade e 
experiência, enquanto o build é responsável pela questão técnica. 


Um design eficiente evita desperdício de tempo e recursos, ou seja, 
a pessoa que joga entende de forma intuitiva o que se deve fazer e 
não fica confusa com uma série de informações inúteis na tela. É o 
estágio do projeto no qual elementos são priorizados previamente e 
especificações técnicas são modificadas. O que for possível decidir 
nesta iteração deve ser feito, e tudo que for mais complexo deve ser 
deixado para as próximas iterações. Para um design bem-sucedido, 
é preciso pensar sobre todas as especificações do jogo, as 
identidades das personagens, as funcionalidades, as mecânicas, a 
experiência da usuária, o enredo e o gameplay. 


Build é onde o desenvolvimento dá seus primeiros passos. Para o 
desenvolvimento de jogos, o build não é somente sobre código, mas 
também sobre arte e efeitos sonoros, os quais não serão abordados 
neste livro. Build é o momento em que decidimos os estilos de 
código, as práticas que vamos utilizar, os processos e ferramentas. 
E é o momento em que decidimos como o código será integrado a 
algumas ferramentas de feedback. 


Desenvolvimento de software nos traz a ideia de Minimum Viable 
Product (MVP) ou, em português, produto mínimo viável, ou seja, O 
mínimo produto que pode ser entregue com valor. Assim, no livro 
Lean Game Development, apresentei o conceito de Minimum Viable 
Game (MVG), que era composto de múltiplos protótipos 
incrementáveis. E cada um desses protótipos deve entregar algum 
tipo de valor, tornando o MVG um conjunto de protótipos jogável em 
muitos sentidos. Um MVG pode ser reelaborado para cada etapa de 
validação, assim como pode ter diversos incrementos. Um 
incremento é uma extensão e nova hipótese para o MVG anterior, 
possibilitando validar novas ideias. Um novo MVG pode ser um 
conjunto de vários MVGs anteriores, no qual validamos conceitos 
como mecânica de jogo e artes. Esse novo MVG nos permitiria, por 
exemplo, partir de minijogos que foram lançados em plataformas 
como itch.io ou board games. 


Das formas de MVG que descrevi anteriormente, eu gosto muito de 
testar uma ideia construindo um "jogo de tabuleiro" que aplique as 
mecânicas que tenho em mente. Ótimos exemplos de jogos que 
funcionam com tabuleiro são jogos de estratégia em tempo real ou 
RPGs. No caso de um RPG, além de ser bem legal testar as 
mecânicas de turno e de movimentação, ele ajuda muito a entender 
o que seria uma boa mecânica de pontuação. Já no caso de jogos 
de estratégia, é interessante ver como fica o movimento de 
unidades e como coordenar um grande conjunto delas. Outro bom 
ponto para avaliar é verificar se o sistema de pontos está adequado, 
como nível de força e defesa de cada unidade. O último ponto que 


um MVG de tabuleiro nos ajuda a verificar é a diversão que teremos. 
Agora podemos nos aprofundar um pouco mais nesses conceitos. 


A seguir, algumas perguntas comuns sobre design, build e MVGs: 


O que seria o design do jogo? Como a personagem principal deve 
ser? Como ela deve se mover? Que experiências desejamos que a 
jogadora tenha? O enredo será suficiente? Como está a 
ambientação do jogo? E qual o melhor gameplay para o nosso jogo? 


E sobre nosso build? Quais ferramentas serão escolhidas? Como 
animaremos? Sera via sprites? Quantas iterações vai levar para 
concluirmos o MVG? E o jogo todo? Como integraremos tudo? 
Como faremos as entregas? Faremos pairing? Como versionaremos 
nosso código? O que já temos de experiências passadas ainda é 
válido? Funciona bem? Devemos migrar? 


E nossos MVGs? Podemos iterar sobre eles? Quantas iterações 
podemos ter? Que tipo de valor queremos em cada iteração? O que 
é o mínimo? O que é o viável? Sabemos validar nossas hipóteses? 
Podemos entregar valor depois do MVG? 


Todas essas questões podem ser trazidas à tona. Por isso, é 
importante pararmos um pouco para pensar em como organizar este 
processo. 


Seleção de ferramentas de Cl 
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Figura 3.1: Ferramentas de Cl. Os padrões de cores mais escuras são as 
engines/frameworks preferidos, enquanto as mais claras apresentam maior rejeição. 


No próximo capítulo, vamos aprofundar mais sobre Cl. 


A definição de qual plataforma vamos utilizar para rodar nosso 
pipeline de Cl (o conjunto de tarefas que definem o processo de 
integração contínua) deve levar em consideração uma série de 
características, como suporte à linguagem e ao framework, 
dificuldade de gerar um pipeline adequado à tarefa, facilidade de 
gerar builds em diferentes sistemas e sua forma de integração. 


Seguindo o exemplo da imagem anterior, as decisões foram 
tomadas com base nos critérios de dificuldade de utilização e 
utilidade. Para nós, a dificuldade de utilizar consistia em 
conhecimento sobre a ferramenta e na necessidade de suporte, já a 
utilidade consistia na capacidade de rodar os diferentes testes e 
gerar builds adequados. Pegando os dois campos mais destacados, 
a Unity Cloud Go era muito simples de utilizar, pois precisava de 
pouquíssimas configurações, mas somente gerava pacotes para 


Unity. Já com o Travis, podíamos executar uma série de tarefas 
distintas e gerar os builds apropriados. 
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Figura 3.2: Engines. Os padrões de cores mais escuras são as engines/frameworks 
preferidos, enquanto as mais claras apresentam maior rejeição. 


Esta imagem deixa bem claro o porquê da escolha de Unity e 
MonoGame para os projetos deste livro. A Unity é uma engine 
completa, possui tudo o que precisamos de uma engine e ela 
permite descrever componentes em Cf. Já o MonoGame é um 
framework voltado a renderização de objetos dentro do loop 
Update/Draw COM CH. 


Agora vamos entender o que seriam os conceitos de utilidade e 
dificuldade: 


Utilidade neste caso é ter uma biblioteca de testes e ser fácil de 
desenvolver um framework completo que minimize os custos de 


desenvolvimento. 


Dificuldade é a barreira de tempo para ter um projeto mínimo e a 
capacidade de integrar com outras ferramentas. 


openGL está no extremo, pois é uma forma cansativa e pouco 
testável de desenvolver games, além de depender fortemente de 
C++, então optar por ele tornaria o livro muito extenso. 


GameMaker e RPGmaker são legais e divertidos para começar, 
mas, além de não possuírem lib de testes, não nos permitiriam 
explorar todos os conceitos que vamos abordar aqui. 


Quanto a Unreal e Cry, ainda teríamos alguma dificuldade com 
conceitos de testes, pois essas engines ainda estão em um estágio 
muito iniciante na jornada de testabilidade, além de dependerem 
fortemente de C++. 
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Figura 3.3: Possíveis entregáveis alto nível para o processo de entrega de valor baseado 
em MVPs. Os padrões de cores estão agrupados de acordo com um conjunto lógico de 
entregáveis por iteração. 


MVPs são muitas vezes confundidos com coisas incompletas ou 
sem valor de negócio, mas, ao contrário do que se pensa, MVPs 
são uma ótima forma de validar o interesse e o sucesso do seu 
projeto, pois nos possibilitam corrigir problemas, de bugs a design, e 
evitam que nosso produto seja falho. 


Os nomes destes MVPs são menos relevantes, pois o que importa 
aqui é validar que nossa ideia de estágios do jogo é adequada e 
pode ser levada adiante. Por exemplo: é sempre importante ter 
protótipos de mecânicas simples e bem-feitas antes de partir para 
mecânicas complexas. Além disso, mecânicas de desafio, como 
chefes, são bastante relevantes para que as pessoas mantenham o 
interesse no jogo. Assim, com protótipos de chefes, podemos validar 
que o jogo é interessante e continuamente mais envolvente. 


Podemos também associar conceitos de artes a essas mecânicas e, 
caso fiquem bons, podemos fazer um release de marketing. É muito 
comum estúdios lançarem vídeos e fotos de seus jogos muito antes 
do lançamento oficial, o que pode gerar as mais diversas reações, 
que são exatamente as métricas que queremos coletar. Depois 
disso, é interessante possibilitar que pessoas diferentes joguem 
partes do jogo e nos deem feedbacks para começarmos a procurar 
bugs mais sérios com betas e early launch. Uma opção final é tentar 
expandir as plataformas nas quais nosso jogo está habilitado, e 
sempre manter updates legais para desenvolver nossa propriedade 
intelectual. 


CAPÍTULO 4 
Por que devemos nos preocupar com Cl? 


Primeiro de tudo, Cl significa Integração Contínua. Isso quer dizer 
que o software vai ser integrado continuamente em um repositório 
compartilhado e, a cada integração, uma ferramenta de build e de 
testes rodará, garantindo a saúde do software. A principal vantagem 
é que isso permite que problemas sejam detectados o mais rápido 
possível, mas no geral temos os seguintes benefícios: 


e Detecção de bugs 

e Controle do código — Uma ferramenta que nos permite saber 
o estado do código e pode rodar frequentemente para identificar 
conflitos. 

e Agente de build — Uma ferramenta de build automatizado 
permite que sempre tenhamos a última versão disponível. 

e Testes Unitários — Garantem que nossos blocos lógicos estão 
corretos com todos os casos imaginados. Associados a testes 
de mutação, integração e outros, eles nos dão uma ideia de 
quão correto está nosso código ao iterar. 

e Testes funcionais automatizados — Isso nos permite 
determinar se todas as funcionalidades estão funcionando bem 
e não estão quebradas. 

e Deploy — Permite entregar um build para update, para teste 
manual e inclusive para vendas. 


“Integração Contínua não nos livra de bugs, mas torna 
dramaticamente mais simples e prático encontrá-los e removê- 
los." 


— Martin Fowler, Cientista chefe, ThoughtWorks 





Mais sobre Cl em https://www.thoughtworks.com/continuous- 
integration/ 


A prática 


e Mantenha um único repositório do projeto. 

e Automatize o build. 

e Faça seu build se testar sozinho. 

e Cada commit deve gerar o build sobre uma máquina de 
integração. 

e Mantenha o build rápido. 

e Teste em uma cópia do ambiente de produção. 

e Permita facilmente que qualquer pessoa tenha acesso à última 
versão executável. 

e Todo mundo pode ver o que está acontecendo. 

e Automatize o deploy. 


Como fazer? 


e Desenvolvedoras descarregam o código em seus workspaces. 

e Quando todas as mudanças estiverem prontas, sao 
commitadas para o repositório compartilhado. 

e Uma estratégia é commitar em uma feature branch e fazer code 
review. Outra seria alinhar bem com o time como são feitos 
commits direto na master. 

e O servidor de Cl monitora o repositório e verifica quando as 
mudanças ocorrem. 

e O servidor de Cl constrói o jogo e roda os testes, sejam 
unitários ou de integração. 

e O servidor de Cl entrega artefatos prontos para serem testados, 
geralmente por beta testers no caso de games. 

e O servidor de Cl designa um label para versão do build recém- 
gerada. 

e O servidor de Cl informa o time se o build foi feito com sucesso. 

e Se o build ou os testes falharam, o servidor de Cl alerta o time. 

e O time corrige os problemas o mais rápido possível. 

e Continue fazendo isso e integrando por toda a duração do 
projeto. 


CODE REVIEW 


É uma possível prática ágil, cujo objetivo é passar conhecimento 
sobre o que está sendo feito para o resto das pessoas do time e 


ter como um retorno sugestões de melhoria. Além disso, 
trabalhar com feature branch permite que você execute a 
pipeline antes de enviar o código para a master. 





Responsabilidades do time 


e Verifique frequentemente. 

e Não faça commit de código quebrado. 

e Não faça commit de código não testado. 

e Não adicione código a um build quebrado, a não ser que seja 
para corrigir o build. 

e Não abandone seu código depois do commit, espere o build 
terminar. 


Muitos times desenvolvem rituais em volta dessas políticas, o que 
na prática faz com que esses times se autogerenciem, eliminando a 
necessidade de políticas hierárquicas. 


4.1 E quanto a Cl para games? 


Há uma grande quantidade de ferramentas de Cl disponíveis que 
são compatíveis com games. As vantagens que se destacam são: 


e Pessoas não desenvolvedoras podem verificar a atual versão 
do jogo. 

e À versão para a mídia pode estar sempre disponível. 

A publisher pode acompanhar e identificar a atual versão do 

jogo. 

A garantia de que o jogo funciona em diferentes plataformas. 


e Há disponibilidade para obter a última versão do build. 
e A facilidade de arrumar bugs. 


Com tudo isso, agora podemos mergulhar mais a fundo no ambiente 
do TDD, garantindo que todo o commit esteja funcionando bem. 


CAPÍTULO 5 
TDD, como começar? 


Agora podemos finalmente falar sobre como desenvolver jogos via 
TDD. Neste capítulo, veremos como gerar casos de testes para um 
mínimo jogo viável. 


Por isso, devemos ter um conceito claro do que é testar em um 
ambiente de jogos e do que é o quê. Algumas destas definições 
podem variar, mas esta é uma abordagem que já usei para jogos e 
gostei. 


Testes Unitários: devem testar uma parte unitária de uma 
classe, como um namespace, uma rotina ou uma função. É o 
tipo de afirmações de testes clássicos em exemplos de TDD. 
Você verá que mais adiante a biblioteca de testes do Cf chama 
estas afirmações de Assert . 

Testes Funcionais: testam se a função ou o objeto interage da 
forma esperada. Por exemplo: "quando x for pressionado, outro 
objeto abre”. 

Testes de Componente: testam se a execução de um objeto 
do jogo, um pacote, uma sub-rotina ou um pequeno programa 
interno estão funcionando como esperado. Por exemplo: um bot 
deveria reagir dentro de certos estados quando vê um jogador. 
Testes de Integração: é um conceito difícil dentro de games, 
porque normalmente a integração com outros sistemas ocorre 
somente com servidores e kinect, o que é relativamente 
moderno na escala atual de jogos. Um bom exemplo disso é a 
integração com o kinect, com ps move OU com o servidor. Isso 
não foi testado neste livro. 

Testes End-to-end: é semelhante à ideia de automatizar todo o 
teste de jogabilidade ou fluxo de jogo (geralmente conhecidos 
como gameplay), o que por sua vez pode ser útil para gerar 
exemplos de fluxo de jogo. 


No livro não dividi os testes de acordo com suas categorias, e sim 
de acordo com suas funcionalidades e classes. Ambas as 
abordagens são válidas e possuem suas vantagens. Escolhi esta 
por ser a mais intuitiva de ler. 


5.1 Casos de teste de um jogo simples 


Falando de um mínimo jogo viável, eu fui inspirada pela ideia de 
quais seriam a mecânica mínima e as features que uma jogadora 
esperaria de um jogo plataforma 2D. Por exemplo, no último projeto 
do qual participei de forma não independente, meus colegas tinham 
dificuldade em entender que primeiro deveríamos ter as mecânicas 
e validá-las para depois fazer o ajuste fino. O resultado foi que eles 
se preocuparam somente com o ajuste fino e quase não deu tempo 
de terminar no prazo, ficou péssimo. 


Poderíamos considerar que as mecânicas centrais do jogo seriam 
as de movimento. Então, na minha opinião, as principais mecânicas 
de um jogo do Mário seriam caminhar, pular e cair. E como 
poderíamos testa-las? 


Feature de caminhada 


Feature Personagem deve se mover no eixo x 
Entrada Input de teclado 
Testes 1. Verifica se uma tecla específica foi pressionada. 


2. Verifica se as teclas direcionais foram pressionadas 
(esquerda/direita ou a/d). 


3. Verifica se, quando a tecla de esquerda for 
pressionada, 0 personagem se move para a 
esquerda. 


Feature 


Saída 


Personagem deve se mover no eixo x 


4. Verifica se, quando a tecla de direita for 
pressionada, o personagem se move para a direita. 


5. Verifica se, quando outras teclas forem 
pressionadas, o personagem não se move. 


6. Verifica se o personagem colide com o cenário. 


Se a nova posição está dentro do esperado, o teste 
passa; se não, ele falha. 


Feature de pulo 


Feature 
Entrada 


Testes 


Saída 


Personagem deve pular 
Input de teclado 
1. Verifica se a barra de espaço foi pressionada. 


2. Verifica se, quando a barra de espaço for 
pressionada, 0 personagem se move na vertical. 


3. Verifica se o personagem se move corretamente de 
baixo para cima (mais de duas afirmações podem ser 
necessárias). 


4. Verifica se o personagem se move corretamente de 
cima para baixo (um ciclo completo de pulo em geral 
leva 5 afirmações). 


5. Verifica se, quando uma tecla direcional é 
pressionada, o pulo ocorre na horizontal também. 


6. Verifica se o pulo é parabólico. 


Se a nova posição está dentro do esperado, os testes 
passam; se não, os testes falham. 


Feature de queda 


Feature Personagem deve cair em buracos 
Entrada Personagem colide com a cena. 
Testes 1. Verifica se o personagem colide com o chão. 


2. Verifica se o personagem colide com blocos 
aéreos. 


3. Verifica se o personagem cai em buracos. 


4. Verifica se, quando o personagem cai em um 
buraco, performa um lançamento horizontal afetado 
pela gravidade. 


5. Verifica se, quando o personagem cai de um bloco 
aéreo, performa um lançamento horizontal afetado 
pela gravidade. 


Saída Se a nova posição está dentro do esperado, os testes 
passam; se não, os testes falham. 
Cada pessoa desenvolvedora pode construir a forma como os testes 
serão feitos e implementados. Entretanto, o mais importante é 
manter os casos de testes simples e suas resoluções ainda mais 
simples. Se alguma etapa não está clara ou é confusa, uma boa 
forma de resolver isso é conceber e executar em etapas 
intermediárias mais simples. Assim, qualquer evolução ou 
refatoração pode se tornar muito menos custosa. 


Neste livro, vamos considerar que, a partir de agora, você já 
entende os princípios básicos do TDD e que, apesar de a solução 
estar na nossa cara, primeiro implementamos um teste cuja solução 
falha e que compila, para depois implementarmos uma solução que 
garante que todos os testes passem. Agora é o momento de 
desenvolvermos nosso jogo com MonoGame aplicando nossa 
estratégia de TDD. 


TDD com MonoGame 


CAPÍTULO 6 
Introdução ao MonoGame 


Antes de vermos como fazer TDD com MonoGame, vou explicar por 
que priorizei este framework e não qualquer outro. A principal razão 
é a extensa quantidade de ferramentas disponíveis para 
desenvolvimento de jogos em CH. Além do mais, uma boa dosagem 
do que temos que implementar, o framework já tem pronto para nós. 
Quando comecei a brincar com desenvolvimento de jogos, comecei 
utilizando OpenGL e, em seguida, lib C++ Allegro. Era uma grande 
dor de cabeça. Em 2008, descobri a biblioteca da Microsoft XNA 
para o desenvolvimento de jogos com foco em Xbox 360. Isso 
mudou minha vida, pois me permitiu desenvolver jogos mais 
rapidamente e com maior qualidade. A XNA era uma biblioteca 
bastante utilizada para jogos, tendo alguns lançamentos de 
sucesso, como Soulcaster e Terraria. Resumindo, a XNA, 
descontinuada em 2010, foi o amor da minha vida de 2008 até 
2012/2013, quando descobri seu sucessor espiritual, o MonoGame. 
Era basicamente a mesma coisa, mas contava com um maior apoio 
da comunidade. O link a seguir possui mais detalhes sobre a XNA, 
mas a sugestão é utilizar o Visual Studio 2010 para que ela 
funcione. Microsoft XNA Framework. Fonte: 
https://en.wikipedia.org/wiki/Microsoft XNA. 


MonoGame começou a ser desenvolvido em 2009 e a última versão 
de suporte exclusivo a 2D foi lançada em 2012. É um framework 
baseado em XNA4 e possui uma comunidade bastante ativa. Alguns 
dos jogos famosos lançados com MonoGame foram FEZ e Bastion. 
Atualmente, MonoGame suporta iOS, Android, macOS, Linux, todas 
as plataformas Windows, OUYA, PS4, PS Vita e Xbox One. 


O repositório GitHub pode ser encontrado em 
https://github.com/MonoGame/MonoGame/. Ele possui uma boa 


pirâmide de testes bastante consistentes. Além disso, existe um 
doc, em inglês, sobre como codar: 
https://github.com/MonoGame/MonoGame/blob/develop/CODESTYL 
E.md/. 


Tutorial em portugués (nao oficial): 
https://medium.com/(Dronildo.souza/monogame-tutorial-parte-1- 
introdu%C3%A7%C3%A30-6e1a3f4d97 3f 


LINKS IMPORTANTES NA COMUNIDADE MONOGAME (EM INGLES): 


e Webpage: http://monogame.net/ 
Comunidade: http://community.monogame.net/ 
Downloads: http://www.monogame.net/downloads/ 
Docs: http://www.monogame .net/documentation/? 
page=main 
Como configurar MonoGame: 
http://www.monogame.net/documentation/? 
page=Setting Up MonoGame 





Por que MonoGame? 


Agora que sabemos um pouco da historia e do processo de 
desenvolvimento do MonoGame, vamos um pouco mais a fundo no 
porqué da escolha deste framework. 


Já vimos anteriormente que MonoGame é um framework de 
desenvolvimento de jogos em C# com um grande apelo comunitário 
e agora precisamos entender como é seu funcionamento. Mas 
antes, vejamos algumas razões para utilizá-lo: 


e Você gosta de Cf; 

e Talvez engines de jogos como Unity, Unreal e Cry sejam muito 
confusas e poderosas; 

e Você gosta mais de codar do que de mover componentes; 

e Você desenvolveu com XNA no passado; 


e Você simplesmente gosta da ideia do MonoGame. 


6.1 Possibilidades de projetos 


Como estou em um macOS, as possibilidades de projeto que tenho 
são um pouco diferentes das possibilidades em Windows. A primeira 
imagem a seguir apresenta as possibilidades de projetos em um 
Mac; a segunda, em Windows. A versão do MonoGame nas 
imagens é a 3.5. 


090 New Project 


Choose a template for your new project 


App General 

Library 

Tests É | MonoGame iPhone/iPad Application O 
O Cloud É MonoGame Android Application 


General 
MonoGame Windows Application 
G 
EM Mac 


f MonoGame Mac Application 
App G 


Library | MonoGame tvOS Application MonoGame iPhone/iPad 
G Application 
@ lor A MonoGame game project for iOS using 
App OpenGL. 
B wos 
App 
Library 


MonoGame 


Library 


O other 


.NET 
Miscellaneous 


Cancel Previous Next 


Figura 6.1: Projetos Monogame no Mac 
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4 Visual C# ( > MonoGame Windows 10 Universal Project Visual C# Windows desktop using DirectX 
b Windows 
web =} MonoGame Android Project tsual C# 
M G Android P Vi IC 
NET Core 
Android ( = MonoGame Content Pipeline Extension Project Visual C# 
Cloud 
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Figura 6.2: Projetos Monogame no Windows 
Vou explicar alguns destes projetos: 


e MonoGame Windows Project: é o projeto padrão para games 
em Windows. 

e MonoGame Mac Application: é o projeto padrão para games 
em macOS. Escolhi este. 

e MonoGame Windows 10 Universal Project: permite criar 
projetos para um ou mais tipos de famílias de dispositivos, 
como desktop, mobile, loT, Xbox e HoloLens. 

e MonoGame Android Project: é o projeto padrão para games 
em smartphones e tablets Android. 

e MonoGame Content Pipeline Extension Project: permite criar 
ou editar seus conteúdos. 

e MonoGame Cross Platform Desktop Project: permite criar 
jogos multiplataformas como Linux, Mac e Windows. 

e MonoGame iOS Project: é o projeto padrão para games em 
iPhones e iPads; será necessário um Mac para fazer deploy no 
App Store. 


Agora precisamos entender a estrutura base de um projeto 
MonoGame. 


O loop do jogo 


Eu gosto da imagem a seguir, porque nos dá uma ideia clara de 
como funciona o loop: 


Carrega sons, fontes, 
imagens 


Carrega 
Conteúdo 
LoadContent() 


Inicializador 


Initialize() 









Verifica entradas e 
atualiza o estado. 


Carrega informações IA e Física 


externas e 


inicializa objetos Atualiza 


Update() 


Desenha 
Draw() 


Limpa a tela, 
redesenha 
sprites e modelos 


Descarrega ou 


UnloadContent() FIM 
Finaliza o 


Conteúdo 


Figura 6.3: Game loop da XNA/Monogame. Adaptado do site geekswithblogs.net 
Como é um pouco difícil de ler, vou resumir: 


e Initialize : carrega recursos externos e inicializa serviços. 

e LoadContent : carrega conteúdo gráfico e sonoro. 

e Update : Ocorre sempre antes de Dpraw() e geralmente tem uma 
frequência de frames entre 25 e 60 fps. Responsável por 
identificar entradas do teclado, realizar computações de IA, 
verificar e aplicar física e atualizar o estado do jogo. 


e Draw: limpa a tela, desenha sprites 2D e modelos 3D. 
e Unloadcontent : algumas vezes não é visível, mas é responsável 
por limpar o estado do jogo e às vezes salvar dados. 


6.2 Iniciando um projeto 


Criei um projeto Mac com o nome de TDD. A imagem a seguir 
representa como está estruturada a solução deste projeto: 


v [mm] tdd (master) 
v | | tdd.MacOS 
€ Getting Started 
v |» References 
SS) MonoGame.Framework 
O System 
O System.Core 
O System.Drawing 
O System.xml 
O System.XmlI.Ling 
O Xamarin.Mac 
v Native References 
O libSDL2-2.0.0 
QO libopenal.1 
Packages 
v |» Content 
v |» Properties 
[0], Assemblyinfo.cs 
[0], Gamet.cs 
[ 1 Icon.ico 
[=], Info.plist 
[3], Main.cs 


[<>]. MonoGame.Framework.dll.config 





Figura 6.4: Solução do projeto 


Nessa solução, temos alguns itens de maior importância, como a 
pasta content , na qual está localizada a ferramenta de pipeline do 
MonoGame, O Icon.ico ,@ OS dois arquivos «cs, Gamel.cs @ Main.cs. 
Vou começar pelo arquivo main.cs , que corresponde à porta de 
entrada para a execução do game loop: 


PIPELINE DO MONOGAME 


A ferramenta de pipeline do MonoGame é uma forma de criar e 
gerenciar conteúdos de projetos, como fontes e sprites. Esses 


arquivos são recebidos crus e, então, são processados para um 
formato .xnb para serem utilizados nos apps do MonoGame. 
Além disso, possui uma interface muito fácil de utilizar. 





#region Using Statements 

using System; 

using System.Collections.Generic; 
using System.Ling; 


using AppKit; 
using Foundation; 
#endregion 


namespace tdd.MacOS 
{ 
static class Program 
{ 
/// <summary> 
/// The main entry point for the application. 
/// </summary> 
static void Main(string[] args) 


{ 
NSApplication.Init(); 


using (var game = new Game1()) 


game.Run(); 


É basicamente uma thread segura para inicializar o game 


runner, a thread de run do game. 





Agora podemos entender o arquivo Game1.cs . Ele começa de forma 
muito mais interessante. Se vocé observar nossos imports, vera que 
estamos utilizando varios do namespace XNA. Isso nao significa 
que estamos utilizando a XNA em si, mas é uma forma de 
homenagear a herança que o MonoGame recebeu da XNA: 


using System; 


using Microsoft.Xna.Framework; 
using Microsoft.Xna.Framework.Graphics; 
using Microsoft.Xna.Framework. Input; 


Depois dos imports, temos a declaração da classe, que estende a 
classe Game . Além disso, temos os atributos privados 
GraphicsDeviceManager graphics € SpriteBatch spriteBatch QUE sao 
encarregados da parte grafica e do gerenciamento de sprites, 
respectivamente. O construtor inicializa graphics e define conteúdo, 
Content, na raiz do diretório, como mostrado na imagem anterior 
com a solução do projeto. 


namespace tdd.MacOS 
{ 
/// <summary> 
/// Gamei é o título do jogo 
/// </summary> 
public class Gamel : Game 
{ 
GraphicsDeviceManager graphics; 
SpriteBatch spriteBatch; 


public Game1() 
{ 


graphics = new GraphicsDeviceManager(this) ; 
Content.RootDirectory = "Content"; 


} 
} 


Depois do construtor, temos os métodos Initialize() € 

LoadContent() . Initialize é onde as informações do jogo devem ser 
inicializadas, já O Loadcontent é onde os conteúdos do jogo devem 
ser carregados, especialmente os conteúdos gráficos, como sprites, 
spritefonts, spritesheets e modelos 3D. Alguns projetos rodam ao 
final do jogo o método unloadcontent() , que serve para diferenciar 
todo o conteúdo carregado, ou até para salvar alguma informação 
importante. 


/// <summary> 

/// Logica de inicialização 

/// Chamar serviços e conteúdos não gráficos 

/// base. Initialize vai enumerar por todos componentes e inicializá-los 
também. 

/// </summary> 

protected override void Initialize() 


{ 
// TODO: Lógica vai aqui 


base.Initialize(); 


/// <summary> 
/// LoadContent é chamado uma vez por jogo e carrega todo seu conteúdo. 
/// </summary> 
protected override void LoadContent() 
{ 

// Construção do SpriteBatch que permite desenhar texturas no método 
Draw. 

spriteBatch = new SpriteBatch(GraphicsDevice) ; 


// TODO: Carrega o conteúdo 
} 


Agora temos a parte mais importante do ciclo de execução de um 
jogo: o loop Update-Draw. Esse loop é responsável por atualizar, 
Update() , todos os estados do jogo, lógica, física etc., para depois 
desenhar o resultado, Draw() . 


/// <summary> 
/// Atualiza o "mundo" do jogo, colisões, inputs e execução de áudio. 
/// </summary> 
/// <param name="gameTime">parametro que provê uma ideia numérica do tempo 
de jogo</param> 
protected override void Update(GameTime gameTime) 
{ 

///Mecânica para sair do Jogo. Para alguns dispositivos esta lógica é 
pré-implementada. 

if (GamePad.GetState(PlayerIndex.One).Buttons.Back == 
ButtonState.Pressed || Keyboard.GetState().IsKeyDown(Keys.Escape) ) 

Exit(); 


// TODO: Adicione sua logica. 


base.Update(gameTime) ; 


/// <summary> 

/// Método chamado para garantir que o jogo se desenhe. 

/// </summary> 

/// <param name="gameTime">parametro que prové uma ideia numérica do tempo 
de jogo</param> 

protected override void Draw(GameTime gameTime) 

{ 


graphics.GraphicsDevice.Clear(Color.CornflowerBlue); 
//TODO: Lógica para desenhar o jogo. 


base.Draw(gameTime) ; 


Então, agora que conhecemos o MonoGame, vamos iniciar nosso 
projeto. 


CAPÍTULO 7 
Configurações 


Este projeto será desenvolvido via TDD utilizando o framework 
MonoGame. Nossos passos para iniciá-lo serão bastante simples: 


e Criar um repositório no GitHub. 

e Criar uma solução para o projeto. 

e Adicionar um teste burro, que inicialmente falhará. 
e Fazer o teste passar. 


7.1 Iniciando um projeto no GitHub 


Faça login em https://github.com/ e crie um novo repositório clicando 
no botão verde new OU em create a New Repository , COMO na imagem 
a seguir: 


e C  @ GitHub, Inc. [US] https://github.com/GameTDD 


GameTDD 


E] Repositories People 1 Teams 0 Projects O Settings 


This organization has no repositories. 


Create a new repository 


Figura 7.1: Criando um repositório no GitHub 


O próximo passo é decidir o nome do repositório, a licença, a 
descrição, a acessibilidade pública e quais arquivos serão ignorados 
(encontrados no .gitignore ). 


Create a new repository 


A repository contains all the files for your project, including the revision history. 


Owner Repository name 

*# GameTDD + / monogame va 
Great repository names are short and memorable. Need inspiration? How about improved-telegram. 
Description (optional) 


Jogo da velha via TDD 


O |: | Public 


Anyone can see this repository. You choose who can commit. 
Private 


You choose who can see and commit to this repository. 


Initialize this repository with a README 
This will let you immediately clone the repository to your computer. Skip this step if you're importing an existing 
repository. 


Add .gitignore: VisualStudio v Add a license: GNU General Public License v3.0 v @) 


Create repository 


Figura 7.2: Informações básicas do repositório 


Por fim, veremos o resultado do processo que fizemos. O nome e a 
dona do repositório, a descrição básica, 
commits/branches/releases/contribuidores, e uma lista de todos os 
arquivos presentes na branch master. 


E] GameTDD / monogame 





<> Code Issues 0 Pull requests O 


Jogo da velha via TDD 


Manage topics 
D 1 commit P 1 branch 
Branch: master ~ New pull request 


© naomijub Initial commit 


B .gitignore 
E) LICENSE 


E) README.md 


EE README.md 


*monogame 


Jogo da velha via TDD 


Figura 7.3: Como se parece o repositório 


Projects 0 


$0 releases 


Initial commit 


Initial commit 


Initial commit 


OuUnwatchr 1 K Star 0 YFork o 


Settings 


Edit 


22 1 contributor as GPL-3.0 


Create new file Upload files Find file Clone or download ¥ 


Latest commit aa18c@e 31 minutes ago 


31 minutes ago 
31 minutes ago 


31 minutes ago 


$ 


Agora precisamos do repositório disponível em nossa própria 
máquina para iniciar o desenvolvimento. Para isso, usamos o 
comando git clone <caminho para o repositorio> COMO na imagem a 
seguir: 





Figura 7.4: Clonando o repositório 


Para subir mudanças no repositório basta seguir estes passos: 


e git add --all OU git add -p : adiciona todos os arquivos para 
serem commitados ou adiciona os arquivos de forma interativa. 


e git commit -m "<Escreva seu comentário aqui>" : especifica o que 
está sendo commitado. 

e git push origin master : envia OS arquivos adicionados para a 
branch master. 


7.2 Criando uma solução 


Eu criei um projeto para Mac por conta do computador que estou 
utilizando no momento, mas as bases de aprendizado se manterão 
constantes, variando pouco de uma plataforma para outra. O 
repositório criado encontra-se no GitHub: 

. À imagem a seguir é o 
projeto vazio funcionando com uma tela azul. 





monogame.MacOS 








(Sp 


Figura 7.5: App base sem nenhuma modificação 


Agora fazemos o commit dele da mesma forma que fizemos 
anteriormente: 


(py3) LAjnaomi:monogame jnaomi$ git status 
On branch master 
Your branch is up to date with 'origin/master'. 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


nothing added to commit but untracked files present (use "git add" to track) 
(py3) LAjnaomi:monogame jnaomi$ git add . 
(py3) LAjnaomi:monogame jnaomi$ git commit -m "Includes monogame project" 
[master a050539] Includes monogame project 
9 files changed, 277 insertions(+) 
create mode 100644 monogame.sin 
create mode 100644 monogame/Content/Content.mgcb 
create mode 100644 monogame/Gamel.cs 
create mode 100644 monogame/Icon.ico 
create mode 100644 monogame/Info.plist 
create mode 100644 monogame/Main.cs 
create mode 100644 monogame/MonoGame.Framework.dll.config 
create mode 100644 monogame/Properties/AssemblyInfo.cs 
create mode 100644 monogame/monogame.MacOS.csproj 
(py3) LAjnaomi:monogame jnaomi$ git push 
Counting objects: 14, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (12/12), done. 
100% (14/14), 17.81 KiB | 2.54 MiB/s, done. 
, reused O (delta 0) 
To github.com:GameTDD/monogame. git 
aal8c0e..a050539 master -> master 
(py3) LAjnaomi:monogame jnaomi$ ff 





Figura 7.6: Commitando o projeto base 


Aqui uma visao mais clara da imagem anterior. 


$ git status 

>> monogame.sin 

>> monogame/ 

$ git add 

$ git commit -m "Includes monogame project" 
>> monogame.sin 

>> monogame/Content/Content.mgcb 

>> monogame/Gamel.cs 

>> monogame/Icon.ico 


>> monogame/Info.plist 

>> monogame/Main.cs 

>> monogame/Monogame.Framework.dll.config 
>> monogame/Properties/AssemblyInfo.cs 

>> monogame/monogame.MacOS.csproj 

$ git push 


7.3 Adicionando um projeto de testes 


Para podermos testar nosso projeto, precisaremos de um novo 
projeto separado dentro da mesma solução. Geralmente recomendo 
a biblioteca NUnit para testar projetos C#. Nao vamos testar o ciclo 
do jogo porque isso é parte do framework MonoGame, e, portanto, é 
o trabalho de suas desenvolvedoras. Devemos sempre escolher 
frameworks que são ativamente testados e com uma comunidade 
consciente nesse sentido. Felizmente, o MonoGame está no 
caminho correto. 


Como sugestão de bibliotecas de testes para Cf, entre as melhores 
estão a NUnit e a NSubstitute. Para adicionar esses pacotes basta 
seguir estes passos: 


v monogame (master) 
> | | Handlers 
> | monogame.MacOS 


v | | monogame.Testes 
+ 
> |» References 





Add NuGet Packages... 
Update 
Restore 





Refresh 


Figura 7.7: Adicionando um package 


1. Clique com o botão direito em packages . 

2. Selecione add Package . 

3. Selecione o nunit (3.11.0). Além disso, caso você queira fazer 
testes de mocks, pode adicionar Nsubstitute , mas neste 
momento vamos focar mais em testes de funções com menos 
estados. Para o caso de um projeto do tipo Nunit Library 
Project , não é preciso adicionar a dependência nunit . 


Podemos agora fazer um teste básico para ver se tudo está 
funcionando bem. Para isso, criamos um teste que falha e não 
compila, como na estrutura a seguir: 


using NUnit.Framework; 
using System; 


namespace monogame. Testes 


{ 
[TestFixture()] 
public class Test 


{ 


private Tester tester; 


[TestFixtureSetUp() ] 
public void TestSetup() 


{ 


tester = new Tester(); 


[Test() ] 
public void TestCase() 


{ 
Assert.That(true, Is.EqualTo(tester.isBool())); 


} 


Agora nosso teste precisa pelo menos compilar. Para isso, 
precisamos criar uma classe Tester e um método isBool , que falhe: 


using System; 
namespace monogame 


{ 

public class Tester 

{ 
public Tester() 
{ 
} 
public bool isBool() 
{ 

return false; 

} 

} 


Se apenas criarmos a classe Tester no projeto monogame , não 
conseguiremos compilar o teste. Para que isso aconteça, devemos 
adicionar a referência do projeto monogame ao projeto monogame.Testes . 
Assim podemos provar que o teste falha e compila: 


4 Test Results 


© Successful Tests Inconclusive Tests © Failed Tests © Ignored Tests | & Output | 


© Test results for monogame. Testes configuration Debug|x86 


4 monogame.monogame.Testes.monogame.Testes.Test. TestCase 


Expected: False 
But was: True 


Passed: O Failed: 1 Errors: O Inconclusive: O Invalid: O Ignored:0 Skipped: O Time: 00:00 


Figura 7.8: Teste que falha e compila 


Com a implementação mais simples possível para fazer o teste 
passar, escrevi o seguinte código: 


using System; 
namespace GameContent 


public class Tester 
{ 
public Tester() 
{ 
} 
public bool isBool() 
{ 
return true; 
} 
} 
} 


Basta commitarmos essa solução inicial ao GitHub e podemos 
começar nossa jornada de TDD para desenvolvimento de jogos. Já 
que temos tudo montado, vamos começar com um jogo da velha, no 


qual poderemos testar cada método ou função com um fluxo de 
TDD e um ambiente configurado. 


7.4 TDD com MonoGame 


Primeiro, é importante demonstrar os conceitos práticos de TDD 
para pegarmos o jeito. Para nosso jogo, podemos testar a cor 
branca como fundo. A escolha de branco é bem simples: nosso 
objetivo é apenas praticar os conceitos de TDD, e, portanto, cores e 
beleza não serão exploradas neste momento. 


O primeiro passo é criarmos um diretório que conterá todos os 
testes relacionados a game scene, OU cena do jogo, e, então, criar um 
arquivo de teste com eles. A estrutura do projeto será conforme a 
imagem a seguir: 


v = monogame (master) 
b E monogame.MacOS 
v EE monogame.Testes 
b References 
b Packages (5 updates) 
v |» GameScene 


+) 


[<>] packages.config 
(0) Test.cs 


Figura 7.9: Atual estrutura do projeto 


Agora devemos escrever um teste que vai, inicialmente, falhar, mas 
que nos permitirá testar se a cor de fundo é a correta. Infelizmente, 
testar o main loop do arquivo Gamei.cs é ineficiente, já que ao 
instanciar a classe Game em um arquivo de teste ela quebra. Além 
disso, um mock não estaria realmente testando o valor que 
setamos. Assim, nosso teste inicial seria: 


[Test()] 
public void IsBackgroundwWhite() 
{ 
Assert.That(Color.White, 
Is.EqualTo(GeneralAttributes.BackgroungColor) ) ; 
} 


Uma ideia geral de como nosso arquivo de teste será está 
apresentada a seguir. Lembre-se de que em C# precisamos de 


algumas coisas mínimas para compilar, o que expande o ciclo do 
TDD para: 


1. Escreva um teste que falhe. 
2. Faça o código compilar. 

3. Faça o teste passar. 

4. Refatore. 


using NUnit.Framework ; 

using System; 

using monogame.MacOS; 

using Microsoft.Xna.Framework; 


namespace monogame. Testes.GameScene 


{ 
[TestFixture() ] 


public class GameConfig 


{ 
[Test()] 
public void IsBackgroundWhite() 


{ 
Assert. That(Color.White, 


Is.EqualTo(GeneralAttributes.BackgroungColor) ) ; 
} 


} 


Vale frisar que, para tornar O monogame.framework disponível na 
solução de testes, é preciso clicar com o botão direito em 
references , selecionar a aba .Net Assembly e clicar em 

MonoGame. Framework.d11 . À versão do framework é a 3.8, conforme a 
imagem a seguir: 





All | Packages | Projects | .Net Assembly 


Assembly Version Path 





EB MonoGame.Framework.dll 3.8.0.76 /Library/Frameworks/Mono.framework/External/xbui 
D nunit.framework.dll 2.6.4.14350 [Users/jnaomi/Documents/monogame/packages/NU) 


Figura 7.10: Incorporando o MonoGame à solução de testes 


Para nosso teste passar por enquanto precisamos apenas de: 


using System; 
using Microsoft.Xna.Framework ; 


namespace monogame 


{ 
public class GeneralAttributes 
{ 
public static Color BackgroungColor() 
{ 
return Color.White; 
} 
} 
} 
e. 


using NUnit.Framework ; 

using System; 

using monogame.MacOS; 

using Microsoft.Xna.Framework ; 


namespace monogame. Testes.GameScene 
{ 
[TestFixture() ] 
public class GameConfig 
{ 
[Test() ] 
public void IsBackgroundWwhite() 


{ 
Assert.That(Color.white, 


Is.EqualTo(GeneralAttributes.BackgroungColor())); 
} 


} 


E parece que nosso teste está passando agora: 


4 Test Results 
© Successful Tests Inconclusive Tests | O Failed Tests © Ignored Tests EH Output l> Rerun Tests 


© Test results for monogame.Testes configuration Debug|x86 


© monogame.monogame.Testes.monogame.Testes.GameScene.GameConfig.lsBackgroundWhite 


Figura 7.11: Teste passando 


Agora podemos comegar nosso jogo. 


CAPÍTULO 8 
Primeiros passos no TDD com jogos 


O primeiro passo será identificar do que se trata o jogo e quais são 
seus casos de teste. Assim, vamos começar nos debruçando sobre 
o que seria um jogo da velha digital. 


O jogo da velha 


e Possui 9 blocos em um tabuleiro 3 x 3. 

e Cada jogador pode ser ou x ou o. 

e Cada jogador joga por turno. 

e Cliques de mouse devem ser identificados dentro de um bloco. 

e Ganha o jogador que completar 3 "peças" sequenciais em linha, 
coluna ou diagonal. 


SEGUNDO JOGADOR 


Neste livro, vamos inicialmente implementar o segundo jogador 
como uma interação de usuário, assim como quando duas 


pessoas jogam. Ao final deste jogo vamos adicionar um segundo 
jogador gerenciado pelo computador de forma aleatória, porém 
uma outra solução possível seria utilizar um algoritmo de 
inteligência artificial fraco conhecido como Minimax. 





8.1 Os primeiros casos de teste 


Na minha opinião, a primeira coisa que precisamos testar é a 
interação via mouse. Se o clique está correto ou se foi dentro da 
área de um bloco, por exemplo. A implementação de um clique de 


botão já exige uma boa dose de desenvolvimento, assim vale 
pensar em um roteiro para fazer isso: 


1. Testar se o estado do mouse é clicked ou clicado. 

2. Testar se somente o atual estado do mouse é clicked (O 
anterior não deve ser clicked ). 

3. Testar se a posição do mouse está dentro de uma região. 

4. Testar se o clique foi dentro da região. 

5. Testar se o estado da região mudou. 

6. Testar se o estado da região não muda quando já foi alterado. 


Começando os testes básicos 


Para isolar a dependência do ciclo de 100p/draw do MonoGame, 
vamos criar o projeto Handlers e incluir o pacote referente ao tipo de 
projeto MonoGame que estamos utilizando, o 
Monogame . Framework .Macos . Além disso, devemos incluir o novo projeto 
Handlers nas referências do projeto de testes e posteriormente no 
projeto do game. Lembre-se de garantir que todas as versões dos 
projetos estejam corretas para funcionarem juntas, mono, 
MonoGame e .NET. 


A vantagem de ter um projeto com toda lógica extraída é a 


facilidade para reaproveitar essa lógica, seja em outros jogos, 
seja na versão desse jogo para outras plataformas. 





Agora vamos ao primeiro teste que propusemos: 1. Testar se o 
estado do mouse é clicked ou clicado e verificar se o estado do 
mouse passado a uma função é equivalente a pressionado, pressed . 
Dessa forma: 


using NUnit.Framework ; 
using Microsoft.Xna.Framework. Input; 


namespace monogame.Testes.Handlers 


{ 


[TestFixture() ] 
public class InputUtils 
{ 


MouseState mouseButtonState; 


[TestFixtureSetUp() ] 
public void TestSetup() 
{ 
mouseButtonState = new MouseState(@, O, O, 
ButtonState.Pressed, ButtonState.Released, ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 


} 
[Test()] 
public void IsClickedShouldReturnTrueForClickedState() 
{ 
Assert.That(Handlers.Input.IsMouseClicked(mouseButtonState), 
Is.True); 
} 


} 


Como esperávamos, o teste falha por erro de compilação já que 
Handlers ainda não existe. Para isso, devemos criar a classe ou o 
namespace Ff (este namespace pode facilmente ser feito em Ff) 


Handlers : 


using Microsoft.Xna.Framework. Input; 


namespace Handlers 


{ 

public class Input 

{ 
public static bool IsMouseClicked(MouseState mouseState) 
{ 

return false; 

} 

} 


v © monogame.monogame.Testes.monogame.Testes.InputUtils.IsClickedShouldReturnTrueForClickedState 


Expected: True 
But was: False 


Figura 8.1: Teste de estado clicado do mouse falha 


Para este teste passar, implementaremos as seguintes mudanças 
no método IsMouseClicked : 


using Microsoft.Xna.Framework. Input; 


namespace Handlers 


{ 
public class Input 
{ 
public static bool IsMouseClicked(MouseState mouseState) 
{ 
if (mouseState.LeftButton == ButtonState.Pressed) 
{ 
return true; 
} 
return false; 
} 
} 
} 


Para matar a curiosidade de como seria em F#: 


namespace Handlers 
open Microsoft.Xna.Framework. Input 


module Input = 
let IsMouseClicked (mouseState: MouseState) : bool = 
if mouseState.LeftButton = ButtonState.Pressed then 
true 
else 
false 


O próximo passo é verificar se o estado anterior ( previousstate ) está 
liberado ( released ) e se o estado atual ( currentstate ) está 


pressionado ( pressed ), OU Seja, 2. Testar se somente o atual 
estado do mouse é clicked (O anterior não deve ser clicked ). 
Este teste será um caso interessante, pois só há um teste real que 
funciona como um click mesmo tendo outros cenários de testes 
que deveriam ser testados, como ambos os estados pressed , ambos 
os estados released , OU ainda, o estado anterior pressed e o atual 


released. 


ENTENDENDO O ar 


Da forma como estamos implementando, só existe uma forma 
de ativar O click, pois estamos procurando somente um fluxo de 
click . Os itens a seguir demonstram cada uma das situações: 


Estado Estado 


E Ação 
anterior atual $ 


Sem click , pois mouse está 


pressionado pressionado , 
pressionado 


Sem click , pois mouse está 
liberado 


liberado liberado 


Sem click , pois mouse foi 


pressionado liberado iberado 


Com click , pois mouse foi 


liberado pressionado , 
pressionado 





Então, vamos alterar o teste anterior para o seguinte formato: 


[TestFixture()] 
public class InputUtils 
{ 


MouseState mouseButtonState; 
MouseState mousePreviousButtonState; 


[TestFixtureSetUp()] 


public void TestSetup() 
{ 
mouseButtonState = new MouseState(@, ©, ©, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 
mousePreviousButtonState = new MouseState(@, O, O, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState.Released, ButtonState.Released) ; 
} 


[Test() ] 
public void IsClickedShouldReturnTrueForClickedState() 


{ 
Assert.That (Handlers. Input. IsMouseClicked(mouseButtonState, 


mousePreviousButtonState), Is.True); 


} 
} 


Esse teste falha agora devido a um erro de compilação e para 
corrigir isso devemos modificar o método IsMouseClicked para 
receber o estado anterior: 


public static bool IsMouseClicked(MouseState mouseState, MouseState 
prevMouseState) 


{ 
if (mouseState.LeftButton == ButtonState.Pressed 
&& prevMouseState.LeftButton == ButtonState.Released) 
{ 
return true; 
} 
return false; 
} 


Além disso, vamos mudar os nomes dos estados do mouse para 
nomes que permitam uma maior testabilidade: 


e mouseButtonState -> buttonPressedState (estado com botão 
pressionado). 

e mousePreviousButtonState -> buttonReleasedState (estado com 
botão liberado). 


O atual cenário de testes com os testes extras é: 


[TestFixtureSetUp()] 
public void TestSetup() 
{ 

buttonPressedState = new MouseState(@, O, ©, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 

buttonReleasedState = new MouseState(@, O, O, ButtonState.Released, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 


} 


[Test() ] 
public void IsClickedShouldReturnTrueForClickedState() 
{ 
Assert. That(Handlers.Input.IsMouseClicked(buttonPressedState, 
buttonReleasedState), Is.True); 


} 


[Test() ] 
public void IsClickedShouldReturnFalseForPressedState() 
{ 
Assert. That(Handlers. Input. IsMouseClicked(buttonPressedState, 
buttonPressedState), Is.True); 


} 


[Test() ] 
public void IsClickedShouldReturnFalseForReleasedState() 
{ 
Assert.That(Handlers.Input.IsMouseClicked(buttonReleasedState, 
buttonReleasedState), Is.False); 


} 


[Test()] 
public void IsClickedShouldReturnFalseForUnclickedState() 
{ 
Assert. That(Handlers. Input. IsMouseClicked(buttonReleasedState, 
buttonPressedState), Is.False); 


} 


Agora percebemos que o teste 
IsClickedShouldReturnFalseForPressedstate falha, pois ele aparenta 
ainda ser um cenário válido. Felizmente, podemos facilmente mudar 
O assert de True para False, pois um mouse em movimento 
pressionado não deve acionar uma região de clique, tornando o 
teste: 


[Test()] 
public void IsClickedShouldReturnFalseForPressedState() 


{ 
Assert. That (Handlers. Input. IsMouseClicked(buttonPressedState, 
buttonPressedState), Is.False); 


} 
Testando regiões 


Vamos agora para o teste: 3. Testar se a posição do mouse está 
dentro de uma região, que introduz a ideia de região. 
Consideraremos a região um retângulo, por ser o mais simples e o 
que usaremos futuramente. O seguinte teste foi escrito com a 
função de testar se o parâmetro x da posição do mouse está dentro 
da região. 


using NUnit.Framework ; 
using Microsoft.Xna.Framework. Input; 
using Microsoft.Xna.Framework; 


namespace monogame.Testes.Handlers 


{ 
[TestFixture()] 
public class GeometryTest 


{ 
MouseState mouseState; 
Rectangle rect; 


[TestFixtureSetUp()] 
public void GeometryTestSetUp() 


{ 
mouseState = new MouseState(50, 80, ©, ButtonState.Pressed, 


ButtonState.Released,ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 
rect = new Rectangle(30, 60, 40, 40); 


} 
[Test()] 
public void StateXPositionIsInRegion() 
{ 
Assert.That(Handlers.Regions.IsInReagion(mouseState.X, rect), 
Is.True); 
} 


} 
Para esse teste compilar, podemos implementar a seguinte função: 


using Microsoft.Xna.Framework; 


namespace Handlers 


{ 
public class Regions 
{ 
public static bool IsInReagion(int mouse, Rectangle rect) 
{ 
return false; 
} 
} 
} 


E para os testes passarem, podemos simplesmente retornar true : 


& Successful Tests Inconclusive Tests @ Failed Tests | © Ignored Tests EH Output l> Rerun Tests 


© Test results for monogame. Testes configuration Debug|x86 

© monogame.monogame.Testes.monogame.Testes.GameScene.GameConfig.lsBackgroundWhite 

© monogame.monogame.Testes.monogame. Testes.GeometryTest.StateXPositionIsInRegion 

© monogame.monogame.Testes.monogame. Testes. |nputUtils.IsClickedShouldReturnFalseForPressedState 
© monogame.monogame.Testes.monogame. Testes.|InputUtils.IsClickedShouldReturnFalseForReleasedState 
© monogame.monogame.Testes.monogame. Testes.InputUtils.IsClickedShouldReturnFalseForUnclickedState 


© monogame.monogame.Testes.monogame. Testes. |nputUtils.IsClickedShouldReturnTrueForClickedState 


Passed: 6 Failed: O Errors: O Inconclusive: O Invalid:0 Ignored:0 Skipped: 0 Time: 00:00:00.0610000 


Figura 8.2: Todos testes passando 


Agora podemos incluir um teste para verificar se x esta fora da 
regiao: 


[Test() ] 
public void StateXPositionIsNotInRegion() 


{ 
MouseState outOfRegionState = 


new MouseState(10, 10, @,ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 
Assert.That(Handlers.Regions.IsInReagion(outOfRegionState.X, rect), 
Is.False); 


} 


Para fazer esse teste passar, podemos realizar a seguinte operação: 


public static bool IsInReagion(int mouse, Rectangle rect) 


{ 


if (mouse >= rect.Left) { 
return true; 


} 


return false; 


} 


Com esse teste, percebemos que, se incluirmos um valor muito 
grande no primeiro teste, O statexPositionIsInRegion , O assert ainda 


será verdadeiro, mas não será correto do ponto de vista de jogo, 
pois somente estamos verificando um dos limites da região. 
Portanto, podemos adicionar um teste e refatorar o anterior: 


[Test ()] 
public void StateXPositionSmallerThanRegion()( 

MouseState outOfRegionState = 

new MouseState(10, 10, ©, ButtonState.Pressed, 

ButtonState. Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 

Assert. That(Handlers.Regions.IsInReagion(outOfRegionState.X, rect), 
Is.False); 
} 


[Test()] 
public void StateXPositionGreaterThanRegion() 


{ 
MouseState outOfRegionState = 


new MouseState(1000, 1000, ©, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState.Released); 
Assert.That (Handlers.Regions.IsInReagion(outOfRegionState.X, rect), 
Is.False); 


} 


Para resolvermos esse teste que falha, devemos expandir a lógica 
de nosso if em IsInRegion, COMO if (mouse >= rect.Left && mouse <= 
rect.Right) . Outro ponto é o fato de que a região não é apenas 
definida por x, mas também por y . Dessa forma, devemos testar o 
estado do mouse para y também. Por isso, faremos o seguinte 
teste: 


[Test()] 
public void StateYPositionIsInRegion() 
{ 
Assert.That(Handlers.Regions.IsInReagion(mouseState.Y, rect), 
Is.True); 


} 


Para esse teste passar, devemos adicionar a lógica contendo o eixo 
Y, && mouse >= rect.Bottom && mouse <= rect.Top , € manter O cenário 
para o eixo x. Assim, nosso teste falha e podemos resolvê-lo da 
seguinte forma: 


public static bool IsInReagion(int mouse, Rectangle rect) 


{ 
if (mouse >= rect.Left && mouse <= rect.Right 
&& mouse >= rect.Bottom && mouse <= rect.Top) { 
return true; 


} 


return false; 


} 


Nosso teste passa, mas agora podemos pensar em como refatorar 
nosso código. As duas repetições que vejo neste código são: 


e Casos de teste de x são iguais aos de y. Para resolver isso, 
podemos simplesmente testar a região. 

e A lógica do if é repetitiva, m >= r.MinX && m <= r.MaxX && m >= 
r.MinY && m <= r.MaxY , então poderíamos substituí-la por alguma 
forma mais simples de testar. 


Com isso, podemos evoluir nossos testes para algo assim: 


[TestFixture()] 

public class GeometryTest 

{ 
MouseState correctMouseState; 
MouseState smallerThanRegionState; 
MouseState greaterThanRegionState; 
Rectangle rect; 


[TestFixtureSetUp()] 
public void GeometryTestSetUp() 
{ 
correctMouseState = 
new MouseState(50, 80, ©, ButtonState.Pressed, 
ButtonState.Released,ButtonState.Released, ButtonState.Released, 
ButtonState.Released); 


smallerThanRegionState = 
new MouseState(10, 10, O, ButtonState.Pressed, 
ButtonState.Released,ButtonState.Released, ButtonState.Released, 
ButtonState.Released); 
greaterThanRegionState = 
new MouseState(1000, 1000, O, ButtonState.Pressed, 
ButtonState.Released,ButtonState.Released, ButtonState.Released, 
ButtonState.Released) ; 
rect = new Rectangle(30, 60, 40, 40); 


[Test()] 
public void MouseStatePositionIsInRegion() 


{ 


Assert.That(Handlers.Regions.IsInReagion(correctMouseState, rect), 
Is.True); 


} 


[Test()] 
public void MouseStatePositionSmallerThanRegion(){ 
Assert.That (Handlers.Regions.IsInReagion(smallerThanRegionState, 
rect), Is.False); 


} 


[Test() ] 
public void MouseStatePositionGreaterThanRegion() 


{ 


Assert. That(Handlers.Regions.IsInReagion(greaterThanRegionState, 
rect), Is.False); 


} 
} 


Infelizmente, nossos testes estão falhando, e para contornarmos 
isso podemos modificar o input de IsInRegion para: 


public static bool IsInReagion(MouseState mouse, Rectangle rect) 


{ 


if (rect.Contains(mouse.X, mouse.Y)) { 
return true; 


return false; 


} 


Com nosso teste passando e nossas redundancias refatoradas, 
podemos prosseguir. 


Uma observação sobre a válida discussão de passar o objeto 
MouseState OU dois valores inteiros mouse.x € mouse.Y : sua 
escolha deve levar em consideração diferenças de performance 
e consumo de memória à medida que seu jogo cresce, mas, 


neste caso, me parece suficiente. Outra solução seria passar 
simplesmente a propriedade Position do estado do mouse, 
podendo até ser transformada em um vector2 com 


estado.Position.ToVector2() . 





Fundindo as funcionalidades de IsInRegion € IsMouseClicked 


Agora vamos implementar o teste 4. Testar se o clique foi dentro 
da região, mas antes gostaria de trazer algumas considerações 
para o teste: 


e Possuímos duas funções que, juntas, podem realizar esta 
validação: IsInRegion © IsMouseClicked . 

e IsInRegion precisa do estado atual do mouse e das instâncias 
do retângulo. 

e IsMouseClicked precisa do estado atual do mouse e do seu 
estado anterior. 

e Para O IsInRegion, O estado anterior pode ser fora da região. 

e Como estamos testando se o mouse interagiu com a região, 
vamos deixar este método na classe Regions. 


Com essas considerações, podemos presumir que nossa nova 
função, HasMouseClickedRegion , possuirá 3 argumentos: o estado atual 
do mouse, o estado anterior do mouse e a região. Assim, nosso 
teste pode ter a seguinte aparência: 


[Test()] 
public void MouseHasClickedRegion() 
{ 
Assert.That (Handlers.Regions.HasMouseClickedRegion(correctMouseState, 
smallerThanRegionState, rect), Is.True); 


} 


Para o teste compilar, basta criarmos o seguinte método em 


Regions : 


public static bool HasMouseClickedRegion(MouseState currentState, 
MouseState prevState, Rectangle rect) 


return false; 


} 


Com nosso teste falhando, podemos fazé-lo passar apenas 
retornando true . Nosso proximo teste pode ser testar se um mouse 
nao clicado na regiao retorna false: 


[TestFixtureSetUp()] 
public void GeometryTestSetUp() 
{ 
correctMouseState = new MouseState(50, 80, ©, ButtonState.Pressed, 
ButtonState.Released, 
ButtonState. Released, 
ButtonState.Released, ButtonState.Released) ; 
unclickedMouseState = new MouseState(50, 80, ©, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 
smallerThanRegionState = new MouseState(10, 10, ©, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 


[Test()] 
public void MouseInRegionNotClicked() 
{ 


Assert.That(Handlers.Regions.HasMouseClickedRegion(unclickedMouseState, 
smallerThanRegionState, rect), Is.False); 


} 


Para fazer esse teste passar, podemos implementar a seguinte 
solugao simples: 


public static bool HasMouseClickedRegion(MouseState currentState, 
MouseState prevState, 
Rectangle rect) 


{ 


return Input.IsMouseClicked(currentState, prevState); 


} 


Agora precisamos de um teste que clique, mas que esteja fora da 
região e retorne falso: 


[Test()] 
public void MouseClickedNotInRegion() 
{ 


Assert. That (Handlers .Regions.HasMouseClickedRegion(greaterThanRegionState, 
unclickedMouseState, rect), Is.False); 


} 


Para esse teste passar, precisamos adicionar mais um teste lógico 
COM IsInRegion : 


public static bool HasMouseClickedRegion(MouseState currentState, 
MouseState prevState, 
Rectangle rect) 
{ 
return Input.IsMouseClicked(currentState, prevState) 
&& IsInReagion(currentState, rect); 


} 


E agora nossos testes passam! 


Caso a organização dos testes não lhe agrade, minhas 
sugestões são aplicar separação de domínio de métodos por 
classe, utilizar a lib Nspec , Utilizar NUnit.TestAdapter com a 


anotação Testcase OU simplesmente utilizar as nomenclaturas 
given, with, when, then para seus testes. Como meu objetivo 
não é explorar as bibliotecas de teste, segui a solução mais 
direta. 





Criando uma região 


Antes de iniciarmos o teste 5. Testar se o estado da região 
mudou, precisamos de um objeto que vai encapsular nosso estado 
da região de forma mais coerente que um Rectangle pode fazer. Por 
isso, vamos começar a pensar em algo mais amigável ao mundo da 
Orientação a Objetos para games. 


Nossa região vai precisar da capacidade de mudar o estado dentro 
da região, entre vazio ' ' e os dois símbolos o e x. Para isso, 
precisaremos de um objeto que contém o Rectangle e que pode 
mudar de estados, como -1, e, 1, algo que vamos chamar de 
Region . Agora, vamos criar um teste que verifique como um objeto 
Region é criado: 


using NUnit.Framework ; 


namespace monogame.Testes.Objects 


{ 
[TestFixture() ] 
public class RegionTest 


{ 


Region region; 


[TestFixtureSetUp()] 
public void SetUpRegion() 
{ 


region = new Region(); 


[Test()] 
public void InitialStateShouldBeZero() 


{ 
Assert.That(region.State, Is.EqualTo(0)); 


} 
Para compilar o teste fizemos esta implementação básica: 


using System; 
namespace monogame.Objects 


{ 
public class Region 
{ 
public int State { get; set; } 
public Region() 
{ 
State = -1000; 
} 
} 
} 


Para esse teste passar, precisamos somente mudar state = -1000 
para state = o , já que estamos considerando somente 3 estados 
-1, ©, 1, sendo ə o estado "vazio". Além disso, precisamos testar 
se a região criada a partir da propriedade rectangle está correta, 
mas isso afetará a forma como implementamos até agora, pois 
devemos substituir todas as chamadas de Rectangle para Region € 
fazer com que a Region tenha conhecimento de suas interações. 


using NUnit.Framework ; 
using Microsoft.Xna.Framework; 
using monogame.Objects; 


namespace monogame.Testes.Objects 


{ 
[TestFixture() ] 


public class RegionTest 


Region region; 


[TestFixtureSetUp()] 
public void SetUpRegion() 


{ 
region = new Region(10, 15, 20, 35); 


[Test()] 
public void InitialAreaShouldEqualRectangle() 


{ 
Assert.That(region.Area, Is.EqualTo(new Rectangle(10, 15, 20, 


Para implementar a solução desse teste, podemos fazer as 
seguintes mudanças na classe Region : 


using Microsoft.Xna.Framework; 


namespace monogame.Objects 


{ 
public class Region 
{ 
public int State { get; set; } 
public Rectangle Area { get; set; } 
public Region(int x, int y, int width, int height) 
{ 
State = ®; 
Area = new Rectangle(x, y, width, height); 
} 
} 
} 


Alterando o estado de uma região 


Ainda temos muitos testes pela frente, então vamos descobrir como 
testar a mudança da propriedade state e quando ela não deveria 
mudar. Assim, o próximo teste já implementa de fato o número 5: 
Testar se o estado da região mudou. Seria algo assim: 


using NUnit.Framework ; 

using Microsoft.Xna.Framework; 

using Microsoft.Xna.Framework. Input; 
using monogame.Objects; 


namespace monogame.Testes.Objects 
{ 
[TestFixture() ] 
public class RegionTest 
{ 
Region region; 
MouseState currentState; 
MouseState previousState; 


[TestFixtureSetUp()] 
public void SetUpRegion() 
{ 
region = new Region(10, 15, 20, 35); 
currentState = new MouseState(20, 40, @, ButtonState.Pressed, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released) ; 
previousState = new MouseState(25, 45, @, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 


} 


[Test() ] 

public void StateChangesTolAfterClick() 

{ 
region. InteractWithRegionState(currentState, previousState) ; 
Assert. That(region.State, Is.EqualTo(1)); 


} 


Para compilar o teste e já fazê-lo passar, podemos fazer o seguinte 
código: 


public void InteractWithRegionState(MouseState current, MouseState 


previous) 
{ 

State = ®ð; 
} 


Para esse teste passar, basta que haja a mudança para state = 1 
do campo state. 


Agora podemos adicionar alguns testes para aumentar a segurança 
como clique fora da região. Não precisamos necessariamente testar 
estado sem clique na região, pois este cenário já foi testado no 
método HasMouseclickedRegion . Mas lembre-se de que, como estes 
testes alteram o estado de Region, a ordem de execução 
interfere. Por isso adicionei O region.State = o; antes do teste 
em si. 


Nosso novo teste ficará assim: 


[Test()] 
public void StateDoesNotChangeAfterClick() 
{ 

region.State = 0; 

MouseState currentStateAux = new MouseState(1000, 40, Q, 
ButtonState.Pressed, ButtonState.Released, 

ButtonState.Released, ButtonState.Released, 

ButtonState.Released); 

region. InteractWithRegionState(currentStateAux, previousState) ; 

Assert.That(region.State, Is.EqualTo(@)); 


[Test()] 
public void StateChangesTolAfterClick() 


region. InteractWithRegionState(currentState, previousState) ; 
Assert.That(region.State, Is.EqualTo(1)); 
} 


Para ambos os testes passarem, devemos implementar algo como: 


public void InteractWithRegionState(MouseState current, MouseState 
previous) 


{ 
if (Regions.HasMouseClickedRegion(current, previous, Area) ) 
{ 
State = 1; 
} 
} 


Impedindo mudança de estado 


Agora estamos nos aproximando do fim deste capítulo, o teste 6. 
Testar se o estado da região não muda quando já foi alterado. 
Para isso, precisamos garantir que uma região com estado já 
alterado não tenha seu estado novamente alterado com um clique. 
Assim, se o estado -1 ou 1 já tiver sido setado, ele não pode ser 
alterado de novo. Para resolver estes problemas eu proponho o 
seguinte teste: 


[Test()] 
public void StateDoesNotCHangeWhenAlreadyClicked() 
{ 

region.State = -1; 


region.InteractWithRegionState(currentState, previousState); 
Assert.That(region.State, Is.EqualTo(-1)); 
} 


Para solucioná-lo, vamos adicionar o seguinte código, if (...) && 
State != -1): 


public void InteractWithRegionState(MouseState current, MouseState 
previous) 


{ 


if (Regions.HasMouseClickedRegion(current, previous, Area) && State != 
-1) 


Neste momento não adiantaria fazer o teste para verificar se o 
estado 1 não seria alterado para 1,ouseja, 1 == 1, pois nosso 
teste lógico sempre seria verdadeiro. Felizmente, sabemos que o 
estado 1 não pode ser alterado e, por isso, vamos criar a função 
IsActive para abstrair essa parte. 


public void InteractWithRegionState(MouseState current, MouseState 
previous) 


if (Regions.Interactive.HasMouseClickedRegion(current, previous, rect) 
&& !IsActive()) 


{ 
State = 1; 
} 
} 
public bool IsActive() { 
if (State == 1 || State == -1) 
{ 


return true; 


return false; 


} 


E nossos testes continuam passando. No próximo capítulo, vamos 
gerenciar o estado conforme diferentes jogadores interagem com a 
região e fazer alguns testes gráficos. 


CAPÍTULO 9 
Criando o Board e gerenciando seu estado 


A primeira coisa de que precisamos em um tabuleiro (board) de jogo 
da velha são as quatro linhas distribuídas para que se formem nove 
quadrados. Para resolver isso, poderíamos utilizar a classe 

Rectangle e deixar esses retângulos em forma de linhas. Além disso, 
seria interessante que eles estivessem organizados em array, com 
precisamente quatro elementos, já que são quatro itens. Primeiro 
vamos verificar se O Board tem um array de quatro itens: 


using NUnit.Framework ; 
using Microsoft.Xna.Framework; 
using monogame.Objects; 


namespace monogame.Testes.Objects 


{ 
[TestFixture()] 


public class BoardConfig 


{ 


Board gameBoard; 


[TestFixtureSetUp()] 
public void BoardTestSetUp() 
{ 


gameBoard = new Board(); 


[Test()] 
public void BoardHasOnly4Lines() 


{ 
Assert.That(gameBoard.lines.Length, Is.EqualTo(4)); 


} 


Primeiro fazemos o teste compilar com: 


namespace monogame.Objects 


{ 
public class Board 
{ 
public int[] lines { get; set; } 
public Board() 
{ 
lines = new int[1]; 
} 
} 
} 


Para nosso teste passar, basta alterarmos O lines = new int[1] para 
lines = new int[4] . Porém, nosso objetivo não é ter um array de 
tamanho 4 e do tipo int, mas sim um array de linhas do tipo 
Monogame . Framework. Rectangle . Então para fazermos esta verificação 
bastaria o seguinte teste: 


[Test()] 
public void LinesAreReactangles() 


{ 
Assert.That(gameBoard.lines[@], Is.InstanceOf<Rectangle>()); 


Assert.That(gameBoard.lines[1], Is.InstanceOf<Rectangle>()); 
Assert.That(gameBoard.lines[2], Is.InstanceOf<Rectangle>()); 
Assert. That(gameBoard.lines[3], Is.InstanceOf<Rectangle>()); 


} 


Note que uma instancia de array em C# nao permite multiplos tipos 
de dados. Assim, nosso teste poderia ser simplificado para testar 
apenas um dos tipos de itens da instancia do array: 


[Test() ] 
public void LinesAreReactangles() 


{ 
Assert.That(gameBoard.lines[@], Is.InstanceOf<Rectangle>()); 


} 


A implementação que faz esse teste passar é: 


using Microsoft.Xna.Framework; 


namespace monogame.Objects 


{ 
public class Board 
{ 
public Rectangle[] lines { get; set; } 
public Board() 
{ 
lines = new Rectangle[4]; 
} 
} 
} 


Além disso, é preciso ter consistência entre a forma dos retângulos. 
Então, criaremos duas propriedades de espessura ( Thickness ) € 
comprimento ( Length ). Um bom teste para isso é: 


[Test()] 

public void ThicknessAndLenghtAreCommonProps () 

{ 
Assert. That(gameBoard.Thickness, Is.EqualTo(10)); 
Assert.That(gameBoard.Length, Is.EqualTo(300)); 


} 


Para fazermos esse teste compilar, basta declararmos as 
propriedades com quaisquer valores iniciais: 


public class Board 

{ 
public Rectangle[] lines { get; set; } 
public int Thickness { get; set; } 
public int Length { get; set;} 


public Board() 

{ 
lines = new Rectangle[4]; 
Thickness = 0; 
Length = 0; 


} 
Para o teste passar, basta mudar os valores assim: 


public Board() 

{ 
lines = new Rectangle[4]; 
Thickness = 10; 
Length = 300; 


DEFININDO CORES 


Para definirmos uma cor precisamos de uma texture com cor, 
porém testar essa texture é bastante complicado e cheio de 
efeitos colaterais, já que ela é dependente da classe 
GraphicsDevice , que, por sua vez, depende da lib soL e da classe 
Game . Sua complexidade para testes pode ser vista nos links: 
https://github.com/MonoGame/MonoGame/blob/develop/Tests/Fr 
amework/Graphics/Texture2D Test.cs 
https://github.com/MonoGame/MonoGame/blob/develop/Tests/Fr 
amework/Graphics/Texture2DNonVisualTest.cs 
https://github.com/MonoGame/MonoGame/blob/develop/Tests/Fr 
amework/Graphics/GraphicsDevice TestFixtureB ase.cs. Mesmo 


sendo um livro sobre TDD, testar a lib exigiria muitas paginas de 
explicação sobre as mais diversas manipulações de objetos, o 
que não é o objetivo aqui. Por esse motivo, implementei o 
método GenerateTextures na classe GeneralAttributes para 
abstrair essa lógica e nos permitir focar no que realmente nos 
interessa: 


public void GenerateTextures(GraphicsDevice graphics) 
{ 

LineTexture = new Texture2D(graphics, 1, 1, false, 
SurfaceFormat.Color); 

Color[] colorData = { Color.White, }; 

LineTexture.SetData<Color>(colorData); 





Agora precisamos testar a posição de cada linha. Minha sugestão é 
implementar cada assert por vez. Por isso eles estão comentados. 


[Test()] 
public void AreRectanglesPositionsCorrect() 


{ 
Assert.That (gameBoard.lines[0].Location, Is.EqualTo(new Point(195, 


100))); 


//Assert.That(gameBoard.lines[1].Location, Is.EqualTo(new Point(295, 
100))); 

//Assert.That(gameBoard.lines[2].Location, Is.EqualTo(new Point(100, 
195))); 

//Assert.That(gameBoard.lines[3].Location, Is.EqualTo(new Point(100, 
295))); 
} 


Para esse conjunto de testes passar, vamos implementar a seguinte 
solução em Board() : 


public Board() 


{ 
lines = new Rectangle[4] { 
new Rectangle(195, 100, ©, 0), 
new Rectangle(295, 100, ©, 0), 
new Rectangle(100, 195, ©, 0), 
new Rectangle(100, 295, ©, 0), 
}; 
} 


Agora que nosso conjunto de testes passa, podemos criar o teste 
para os tamanhos das linhas: 


[Test()] 
public void TestIfRectanglesSizeAreCorrect() 
{ 
Assert.That(gameBoard.lines[@].Size, Is.EqualTo(new Point(10, 300))); 
//Assert.That(gameBoard.lines[1].Size, Is.EqualTo(new Point(10, 
300))); 
//Assert.That(gameBoard.lines[2].Size, Is.EqualTo(new Point(300, 
10))); 
//Assert.That(gameBoard.lines[3].Size, Is.EqualTo(new Point(300, 
10))); 
} 


Que resultaria no seguinte construtor da classe Board: 


public Board() 


{ 
Thickness = 10; 


Length = 300; 

lines = new Rectangle[4] { 
new Rectangle(195, 100, Thickness, Length), 
new Rectangle(295, 100, Thickness, Length), 
new Rectangle(100, 195, Length, Thickness), 
new Rectangle(100, 295, Length, Thickness), 

>; 

} 


Podemos refatorar nosso teste de modo a utilizar a anotação 
TestCase . Como ambos os valores são propriedades de Rectangle , 
poderíamos testar individualmente da seguinte forma: 


[TestCase(@, 195, 100) ] 
[TestCase(1, 295, 100) ] 
[TestCase(2, 100, 195)] 
[TestCase(3, 100, 295)] 
public void AreRectanglesPositionsCorrect(int i, int x, int y) 
{ 
Assert.That(gameBoard.lines[i].Location, Is.EqualTo(new Point(x, y))); 


} 
Ou poderíamos testar todo o objeto, eliminando redundâncias: 


[TestCase(0, 195, 100, 10, 300) ] 

[TestCase(1, 295, 100, 10, 300) ] 

[TestCase(2, 100, 195, 300, 10)] 

[TestCase(3, 100, 295, 300, 10)] 

public void AreRectanglesPropertiesCorrect(int i, int x, int y, int w, int 
h) 


{ 
Assert.That(gameBoard.lines[i], Is.EqualTo(new Rectangle(x, y, w, 


h))); 
} 


Desenhando o Board 


Implementamos toda a lógica, mas não vemos nada ainda, por isso 
precisamos de uma confirmação visual de que nossas linhas foram 
criadas e estão sendo desenhadas. Para isso, criaremos o método 
Draw na classe Board . Esse método será chamado dentro do 


método Draw do jogo, Game1 (a classe responsável pela execução 
do jogo, conforme vimos na seção Iniciando um projeto). Como o 
método depende de outra classe mais complexa, como SpriteBatch , 
nossos testes serão limitados e mais visuais. Nosso objetivo é ver o 
tabuleiro do jogo da velha conforme a imagem a seguir: 


monogame.MacOS 





Figura 9.1: Objetivo do "teste visual" 


public void Draw(SpriteBatch sb) 
{ 


foreach (Rectangle line in lines) { 
sb.Draw(GeneralAttributes.LineTexture, line, Color.White); 


w 


SPRITEBATCH 


SpriteBatch é a principal classe do MonoGame responsável por 
controlar o desenho das coisas 2D na tela. Ela possui várias 
formas polimórficas e é usada extensivamente pelos métodos de 
desenho praw. Quando você cria um método praw que vai 
desenhar algo na tela, é importante que O spriteBatch esteja 
disponível, já que ele gerencia os desenhos. No template padrão 


do MonoGame, esta classe já vem com a instância e com o 
conhecimento do GraphicsDevice que usará, mas se por algum 
motivo seus sprites (nome para desenhos 2D na tela) não 
estiverem sendo renderizados, os principais motivos podem ser: 
1. métodos Draw não estão sendo chamados pelo principal, 2. 
métodos Draw não receberam spriteBatch como argumento ou 
3. a inicialização do spriteBatch está com problemas. 





Precisamos chamar este método Draw no ciclo de Draw de Games. 
Para fazer isso, basta adicionar o campo da seguinte forma em 
Game1 . Note que para utilizar a propriedade spriteBatch é necessário 
inicializá-la com Begin e uma ordenação preferida, como 
SpriteSortMode.Deferred , para depois finalizá-la com End: 


protected override void Draw(GameTime gameTime) 


{ 


graphics.GraphicsDevice.Clear(GeneralAttributes.BackgroundColor()); 
spriteBatch.Begin(SpriteSortMode.Deferred); 
board.Draw(spriteBatch); 

spriteBatch.End(); 


base.Draw(gameTime) ; 


SPRITESORTMODE 


O spritesortMode é um enum que define a ordem de 
renderização dos sprites para O spriteBatch . Suas possibilidades 
são: 


Deferred: todos os sprites são desenhados no momento em 
que a função End do SpriteBatch é chamada. Assim, eles 
são desenhados em ordem de chamada pelo Draw, 
ignorando qualquer senso de profundidade. 

Immediate: cada sprite é desenhado no momento em que 


seu Draw é chamado, ignorando a função End do 
SpriteBatch . À profundidade também é ignorada. 

Texture: similar ao Deferred , exceto pela ordem de 
desenho, que não é pela chamada de praw , mas sim pelas 
texturas. 

BackToF ront: desenhos são feitos em ordem de chamada, 
como no Deferred , mas a ordem é feita pela profundidade 
de trás para frente antes de desenhar. 

FrontToBack: semelhante ao BackToFront , exceto pela 
ordem, que é feita pela profundidade de frente para trás. 





Com este método board.Draw() sendo chamado, ao tentarmos rodar 
a aplicação, obtemos um erro referente a um parâmetro não 
inicializado. O parâmetro é texture , que está presente na criação da 
textura em Generalattributes.LineTexture . Veja que agora a classe 
Generalattributes possui a propriedade estática LineTexture . Isso foi 
feito a fim de acelerar o uso e aplicar essa propriedade de forma 
mais simples. A nova implementação refatorada da classe fica 
assim: 


public class GeneralAttributes 


{ 
public static Texture2D LineTexture { get; set; } 


public void GenerateTextures(GraphicsDevice graphics) 


LineTexture = new Texture2D(graphics, 1, 1, false, 
SurfaceFormat.Color) ; 

Color[] colorData = { Color.Black }; 

LineTexture.SetData<Color>(colorData) ; 


} 


Para corrigirmos o erro no parâmetro texture, devemos inicializar 
GeneralAttributes € chamar seu método GenerateTextures : 


public class Gamel : Game 


{ 
GraphicsDeviceManager graphics; 
SpriteBatch spriteBatch; 
Board board; 
GeneralAttributes generalAttributes; 


public Game1() 
{ 


graphics = new GraphicsDeviceManager (this); 
Content.RootDirectory = "Content"; 


protected override void Initialize() 


{ 
generalAttributes = new GeneralAttributes(); 
generalAttributes.GenerateTextures(graphics.GraphicsDevice) ; 
base. Initialize(); 


protected override void LoadContent() 


{ 
spriteBatch = new SpriteBatch(GraphicsDevice) ; 
board = new Board(); 


} 


Com isso em ordem, podemos gerar o build e ver a imagem 
desejada. Infelizmente, estas partes do código em que dependemos 


muito da biblioteca monogame são altamente acopladas e dificultam 
muito qualquer uso de substitutes (biblioteca de fakes e mocks para 
a biblioteca de testes NUnit do CH). 


O último ponto que quero salientar é o uso do atributo 
IsMouseVisible . AO rodarmos a aplicação, podemos perceber que o 
mouse desaparece quando se sobrepõe a ela, assim, a solução é 
declarar o parâmetro no construtor de Games : 


public Gamei() 
{ 


graphics = new GraphicsDeviceManager (this) ; 
Content.RootDirectory = "Content"; 
IsMouseVisible = true; 


9.1 Regiões do Board e seus estados 


Agora precisamos garantir que as regiões criadas fiquem entre as 
linhas definidas anteriormente. Ao pensarmos na solução para isso, 
precisamos testar as regiões em si, testar os estados das regiões de 
forma mais funcional e testar se o click, considerando o ambiente do 
jogo, foi dentro da região, o que não é trivial. 


O primeiro teste poderia verificar se existem nove Region, O que não 
significa que vamos testar novamente tudo o que já testamos em 
relação às regiões. Vamos apenas testar se elas não se sobrepõem 
as linhas que acabamos de criar, pois isso significaria que as 
regiões estão deslocadas. Esse é um pensamento interessante, pois 
representa bem as ideias do TDD, de testarmos a base 
suficientemente para não precisarmos encher de testes 
redundantes. Assim, podemos considerar que até agora a classe 
Region está bem testada. O primeiro teste seria algo como: 


[Test()] 
public void BoardHas9Regions() 


Assert.That (gameBoard.regions.Length, Is.EqualTo(9)); 
} 


A partir de agora, vamos fazer a implementação básica para 
compilar o teste. Um teste que não compila é um teste que falha. 
Com o código compilado é possível fazer uma implementação que 
faça o teste ser bem-sucedido. Assim, para esse teste passar basta 
o seguinte código em Board (incluí algumas refatorações na classe 
Board ): 


const int BASE INVERT AXIS = 100; 
const int FIRST POSITION = 195; 
const int SECOND POSITION = 295; 


public Rectangle[] lines { get; set; } 
public Region[ |] regions { get; set; + 


public Board() 


{ 
lines = new Rectangle[4] { 
new Rectangle(FIRST_POSITION, BASE_INVERT_AXIS, Thickness, 
Length), 
new Rectangle(SECOND_POSITION, BASE_INVERT_AXIS, Thickness, 
Length), 


new Rectangle(BASE_INVERT_AXIS, FIRST_POSITION, Length, 
Thickness), 
new Rectangle(BASE_INVERT_AXIS, SECOND_POSITION, Length, 
Thickness), 
> 
regions = new Region[9]; 


} 
Agora precisamos testar se nao há sobreposição entre as partes: 


[Test() ] 
public void CenterRegionDoesNotOverlapsLines() 


{ 


Assert.That(HasOverlap(gameBoard.regions[0].Area, gameBoard. lines), 


Is.False); 
} 


Esta função Hasoverlap não pertence a um domínio específico do 
jogo, porém é uma função útil para testes, por isso vamos 
implementá-la na classe BoardConfig : 


public bool HasOverlap(Rectangle rect, Rectangle[] lines) { 
for (int i = 0; i < lines.Length; i++) { 
if (rect.Intersects(lines[i])) { 
return true; 


} 


return false; 


} 


Mas agora nossa função efetivamente falha e precisamos 
implementar as regiões de maneira que elas não se sobreponham 
para o teste passar: 


public Board() 
{ 


regions = new Region[9] { 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94), 
new Region(100, 100, 94, 94) 

>; 

} 


Porém, agora todas as nossas regiões se sobrepõem, então temos 
que utilizar novamente a função Hasoverlap do seguinte modo: 


[TestCase(@) ] 
[TestCase(1) ] 


[TestCase(2)] 

[TestCase(3)] 

[TestCase(4)] 

[TestCase(5)] 

[TestCase(6)] 

[TestCase(7)] 

[TestCase(8)] 

public void RegionsDoNotOverlap(int x) 
{ 

Rectangle[] rectangles = new Rectangle[9] { 
gameBoard.regions[@].Area, 
gameBoard.regions[1].Area, 
gameBoard.regions[2].Area, 
gameBoard.regions[3].Area, 
gameBoard.regions[4].Area, 
gameBoard.regions[5].Area, 
gameBoard.regions[6].Area, 
gameBoard.regions[7].Area, 
gameBoard.regions[8].Area, 

}; 

Assert.That(HasOverlap(gameBoard.regions[x].Area, rectangles), 

Is.False); 


} 


Agora, a função Hasoverlap vai passar a apresentar conflito quando 
tentar validar se uma região se sobrepõe a si mesma. Então, vamos 
passar um índice que valide qual a posição atual: 


[Test()] 
public void CenterRegionDoesNotOverlapsLines() 


{ 


Assert. That (HasOverlap(gameBoard.regions[@].Area, gameBoard. lines, 
-1), Is.False); 


} 
[TestCase(@) ] 


[TestCase(8) ] 
public void RegionsDoNotOverlap(int x) 


{ 
Rectangle[] rectangles = new Rectangle[9] { 


> 
Assert.That (HasOverlap(gameBoard.regions[x].Area, rectangles, x), 
Is.False); 


} 


public bool HasOverlap(Rectangle rect, Rectangle[] lines, int idx) 
{ 


for (int i = 0; i < lines.Length; i++) 


{ 
if (i != idx && rect.Intersects(lines[i])) 
{ 
return true; 
} 
} 


return false; 


} 
Agora podemos implementar nossas regiões com mais calma: 


public Board() 
{ 


regions = new Region[9] { 
new Region(100, 100, 94, 94), 
new Region(206, 100, 88, 94), 
new Region(306, 100, 94, 94), 
new Region(100, 206, 94, 88), 
new Region(206, 206, 88, 88), 
new Region(306, 206, 94, 88), 
new Region(100, 306, 94, 94), 
new Region(206, 306, 88, 94), 
new Region(306, 306, 94, 94) 

>; 

} 


Além disso, podemos testar se todas as regiões não se sobrepõem 
as linhas utilizando novamente a anotação Testcase : 


[TestCase(@) ] 
[TestCase(1) ] 


[TestCase(2)] 
[TestCase(3)] 
[TestCase(4)] 
[TestCase(5)] 
[TestCase(6)] 
[TestCase(7)] 
[TestCase(8)] 
public void CenterRegionDoesNotOverlapsLines(int x) 
{ 
Assert. That (HasOverlap(gameBoard.regions[x].Area, gameBoard. lines, 
-1), Is.False); 
} 


Lidando com o estado do mouse 


Agora precisamos testar se o clique do mouse retorna a regiao 
correta. Anteriormente, ja implementamos testes que detectam se a 
região foi clicada e outros que detectam que, na região clicada, o 
estado é alterado. Unificando essas duas ideias temos os testes a 
seguir: 


using NUnit.Framework ; 

using System; 

using Microsoft.Xna.Framework. Input; 
using monogame.Objects; 


namespace monogame.Testes.Handlers 
{ 
[TestFixture()] 
public class StateManagerTest 
{ 
Board gameBoard; 
BoardStateManager stateManager; 
MouseState currentState, previousState; 


[TestFixtureSetUp()] 
public void StateManagerSetUp() 
{ 
gameBoard = new Board(); 
stateManager = new BoardStateManager(); 


previousState = new MouseState(250, 250, 0, 
ButtonState.Released, ButtonState.Released,ButtonState.Released,ButtonState 
. Released, ButtonState.Released); 
} 


[Test() ] 
public void MouseClickedRegion4() 


{ 
currentState = new MouseState(250, 250, 0, 


ButtonState.Pressed,ButtonState.Released,ButtonState.Released,ButtonState. 
Released,ButtonState.Released); 


Assert.That (stateManager.ClickedRegion(gameBoard.regions, 
currentState, previousState), Is.EqualTo(4)); 


} 


} 


V u ClickedRegion , 

Para resolver esse teste bastou retornar 4 em cai gi mas 
perceba que também precisamos testar se o clique foi fora da região 
e se outra região foi clicada. Seguem os testes mencionados: 


[Test ()] 
public void MouseClickedRegion®@() 
{ 

currentState = new MouseState(105, 105, O, 
ButtonState.Pressed, ButtonState. Released, ButtonState. Released, ButtonState. 
Released, ButtonState.Released) ; 


Assert. That (stateManager.ClickedRegion(gameBoard.regions, 
currentState,previousState), Is.EqualTo(@)); 
} 


[Test()] 
public void ClickIsOutsideRegions() 
{ 

currentState = new MouseState(50, 50, @, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 


Assert. That(stateManager.ClickedRegion(gameBoard.regions, 


currentState, previousState), Is.EqualTo(-1)); 
} 


A implementação para esses três testes pode ser algo assim: 


using System; 
using Microsoft.Xna.Framework. Input; 
using Handlers; 


namespace monogame.Objects 


{ 


public class BoardStateManager 


{ 
public BoardStateManager(){} 


public int ClickedRegion(Region[] regions, MouseState current, 
MouseState prev) { 
for (int i = 0; i < regions.Length; i++) 
{ 
if (Regions.HasMouseClickedRegion(current, prev, 
regions[i].Area)) 
{ 


return i; 


} 


return -1; 


} 


De graça, ganhamos o seguinte teste que verifica se a região esta 
em cima de uma das linhas: 


[Test()] 
public void ClickInSeparatorLinesRetunsNegative() 
{ 

currentState = new MouseState(196, 101, O, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState.Released) ; 

Assert. That (stateManager.ClickedRegion(gameBoard.regions, 


currentState,previousState), Is.EqualTo(-1)); 
} 


O commit com essas refatorações pode ser encontrado aqui: 
https://github.com/GameTDD/monogame/commit/757 1a7d2d4d7750 
0602d69fcfb21c4c304924f02. 


Cliques mudam o estado da regiao 


Agora sabemos que conseguimos detectar se um clique foi na 
região, mas precisamos garantir que esse clique também altera o 
estado da região. Assim, o seguinte teste nos permite verificar se o 
estado da região mudou após o clique: 


[Test()] 
public void TestIfClickedRegionHasChangedState() 
{ 
currentState = new MouseState(250, 250, ©, ButtonState.Pressed, 

ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 

stateManager .UpdateClickedRegionState(gameBoard.regions, currentState, 
previousState) ; 

Assert. That(gameBoard.regions[4].state, Is.EqualTo(1)); 


} 
Uma possível solução seria: 


public void UpdateClickedRegionState(Region[] regions, MouseState current, 
MouseState prev) 


{ 
var idx = ClickedRegion(regions, current, prev); 
if (idx != -1) 
{ 
regions[idx].InteractWithRegionState(current, prev); 
} 
} 


Como refatoração, agora poderíamos eliminar a validação 
HasMouseClickedRegion de InteractWithRegionState , porque esse método 


já está sendo aplicado em clickedRegion . Assim, podemos tornar 
essa validação mais simples utilizando apenas O Isactive : 


public void InteractWithRegionState(MouseState current, MouseState 


previous) 
{ 
if (!IsActive()) 
{ 
State = 1; 
} 


} 


Além disso, podemos retirar os argumentos mouseState current, 
MouseState previous , dessa forma: 


public void InteractWithRegionState() 


{ 
if (!IsActive()) 
{ 
state = 1; 
} 
} 


Agora precisamos fazer mais algumas refatorações, pois isso 
quebra os testes: 


//Objects/BoardStateManager.cs 
public void UpdateClickedRegionState(Region[] regions, MouseState current, 
MouseState prev) 


{ 
var idx = ClickedRegion(regions, current, prev); 
if (idx != -1) 
{ 
regions[idx].InteractWithRegionState() ; 
} 
} 


//Objects/RegionTest.cs 

[Test()] 

[Ignore()] //Um smell como sinal para deletar teste 
public void StateDoesNotChangeAfterClick() 


region.State = @; 
region. InteractWithRegionState(); 
Assert.That(region.State, Is.EqualTo(@)); 


} 
[Test()] 
public void StateChangesTolAfterClick() 
{ 
region. InteractWithRegionState(); 
Assert.That(region.State, Is.EqualTo(1)); 
} 
[Test()] 
public void StateDoesNotCHangeWhenAlreadyClicked() 
{ 
region.State = -1; 
region. InteractWithRegionState() ; 
Assert.That(region.State, Is.EqualTo(-1)); 
} 


Podemos ver que o teste stateDoesNotChangeafterclick deixa de fazer 
sentido, pois esta validação não ocorre mais nesse espectro. Incluí 
um [Ignore()] no teste, mas no meu commit deletei este teste. 


Outra possibilidade de refatoração é remover os estados do mouse 
( MouseState ) da chamada de UpdateCLickedRegionState © passar a 
região clicada ( CheckRegion ) como um inteiro para o método: 


//Objects/BoardStateManager 
public void UpdateClickedRegionState(Region[] regions, int clickedRegion) 
{ 
if (clickedRegion != -1) 


{ 
regions[clickedRegion].InteractWithRegionState(); 


//Handler/StateManagerTest 
[Test()] 
public void ClickedRegionHasChangedState() 


currentState = new MouseState(250, 250, ©, ButtonState.Pressed, 
ButtonState.Released, ButtonState.Released, ButtonState.Released, 
ButtonState. Released); 

var idx = stateManager.ClickedRegion(gameBoard.regions, currentState, 
previousState) ; 

stateManager.UpdateClickedRegionState(gameBoard.regions, idx); 

Assert. That(gameBoard.regions[4].State, Is.EqualTo(1)); 


9.2 Permitindo a atuagao de diferentes jogadores 


Precisamos testar se cada jogador altera o estado de uma regiao de 
forma alternada, ou seja, uma vez para cada. Para testar isso, 
precisamos garantir que quando um clique ocorrer na regiao n seu 
estado mude para 1 e o seguinte clique, na região n+1, mude o 
estado da região n+1 para -1: 


[Test()] 
public void DifferentClickedRegionsHaveDiffStates() 


{ 
gameBoard.regions[3].InteractWithRegionState(); 


Assert.That (gameBoard.regions[3].State, Is.EqualTo(-1)); 
gameBoard.regions[4].InteractWithRegionState(); 
Assert.That (gameBoard.regions[4].State, Is.EqualTo(1)); 


} 


O teste anterior é dependente de ordem, o que se deve à 
implementação que faremos a seguir. Além disso, esse teste falha, 
pois a implementação atual de InteractwithRegionstate sempre 
retorna 1, conforme a seguir: 


public void InteractWithRegionState() 


{ 
if (!IsActive()) 


{ 
state = 1; 


} 


Neste momento, vamos ignorar esse teste para fazer a 
implementação de sua solução, que exigirá alguns testes extras. 
Assim, vamos criar uma variavel estatica chamada currentPlayer : 


public class BoardStateManager 


{ 
public static int currentPlayer { get; set; } 


public BoardStateManager() 
{ 


currentPlayer = 1; 


} 


Um teste simples para garantir que o valor de currentPlayer altera a 
cada interação com O Boara seria conforme a seguir: 


[Test()] 
public void PlayerStateHasUpdated() 
{ 
BoardStateManager.currentPlayer = 1; 
BoardStateManager .UpdatePlayerState(); 
Assert. That(BoardStateManager.currentPlayer, Is.EqualTo(-1)); 
BoardStateManager .UpdatePlayerState(); 
Assert. That(BoardStateManager.currentPlayer, Is.EqualTo(1)); 


} 
Ele é facilmente resolvido com a seguinte implementação: 


public class BoardStateManager 


{ 
public static int currentPlayer { get; set; } 


public BoardStateManager() 
{ 


currentPlayer = 1; 


public static void UpdatePlayerState() 1 
currentPlayer = -currentPlayer; 


} 


Agora que nosso teste passa, podemos fazer o teste anterior passar 
com: 


//Objects/Region 
public void InteractWithRegionState() 


{ 
if (!IsActive()) 


{ 


State = BoardStateManager.currentPlayer; 
BoardStateManager .UpdatePlayerState(); 


} 


Nosso próximo passo é efetivamente poder jogar via testes, o que 
veremos no próximo capítulo. 


CAPÍTULO 10 
Dando vida ao jogo 


Como próxima etapa do que já temos, o que deveríamos ver agora 
é um x ou um o dentro da região que foi clicada. Depois disso, 
precisaremos checar as regiões disponíveis, permitir que a CPU 
selecione uma região e, por último, testar o resultado e verificar se 
algum jogador venceu o jogo. 


Para exibir um x ou um o, precisamos do spriteront , que pode ser 
encontrado usando a lib using Microsoft.Xna.Framework.Graphics , 
modificando o método Loadcontent() , como a seguir: 


public class Gamel : Game 


{ 
SpriteFont font; 
protected override void LoadContent() 
{ 
spriteBatch = new SpriteBatch(GraphicsDevice) ; 
font = Content.Load<SpriteFont>("font"); 
board = new Board(); 
} 
} 


O primeiro teste deveria retornar "x" para state = 1: 


[Test()] 
public void XIsReturnedFor1() 
{ 


region.State = 1; 
Assert.That(region.GetSymbol(), Is.EqualTo("X")); 
} 


Uma possível implementação para fazer o teste compilar seria a 
seguinte, em region.cs : 


public string GetSymbol() 
{ 


return ""; 


} 


Para esse teste passar, bastaria mudar O return ""; para return 
"x"; . Agora, semelhantemente, precisamos de outro teste que 
retorne "o" para state = -1: 


[Test()] 
public void OIsReturnedForMinus1() 
{ 

region.State = -1; 


Assert.That(region.GetSymbol(), Is.EqualTo("0")); 
} 


Para resolver esse teste, basta um simples if : 


public string GetSymbol() 


{ 
if (State == 1) { 
return "X"; 
} 
return "0"; 
} 


Falta apenas um teste para garantir que, se o estado não for 1 ou 
-1 , retornamos uma string vazia. 


[Test()] 
public void EmptyStringForo() 


{ 
region.State = @; 
Assert.That(region.GetSymbol(), Is.EqualTo("")); 
} 


Para que esse teste passe, uma pequena mudança é necessária: 


public string GetSymbol() 
{ 

if (State == 1) 

{ return "X"; } 


else if (State == -1) 
{ return "0"; } 
return ""; 


10.1 Imprimindo os simbolos corretos 


Para desenhar uma string, precisamos passar um SpriteFont para O 
construtor do Board em Gamei.cs . Podemos começar passando um 
SpriteFont nulo nos testes. O primeiro passo será definir uma região 
na qual a string será exibida. Agora vamos ver como fica o board e 
as regions com spriteront : 


namespace monogame.Testes.Objects 
{ 

[TestFixture() ] 

public class RegionTest 


{ 


[TestFixtureSetUp()] 

public void SetUpRegion() 

{ 
SpriteFont font; 
region = new Region(10, 15, 20, 35, font); 
} 


namespace monogame.Testes.Objects 


{ 
[TestFixture()] 


public class BoardConfig 


{ 


Board gameBoard; 


[TestFixtureSetUp() ] 
public void BoardTestSetUp() 


{ 
SpriteFont font = null; 


gameBoard = new Board(font); 


namespace monogame.Testes.Handlers 


{ 
[TestFixture()] 


public class StateManagerTest 


{ 
[TestFixtureSetUp()] 


public void StateManagerSetUp() 


{ 
SpriteFont font = null; 


gameBoard = new Board(font); 


} 


} 


Para nossos testes compilarem, devemos modificar os construtores 
para receberem um SpriteFont : 


namespace monogame .Macos 


{ 
public class Game1 : Game 
{ 
protected override void LoadContent() 
{ 
spriteBatch = new SpriteBatch(GraphicsDevice); 
font = Content.Load<SpriteFont>("font"); 
board = new Board(font); 
} 
} 
} 


namespace monogame.Objects 


{ 


public class Board 


{ 


public Board(SpriteFont font) 
{ 


regions = new Region[9] { 
new Region(100, 100, 94, 94, font), 
new Region(206, 100, 88, 94, font), 
new Region(306, 100, 94, 94, font), 
new Region(100, 206, 94, 88, font), 
new Region(206, 206, 88, 88, font), 
new Region(306, 206, 94, 88, font), 
new Region(100, 306, 94, 94, font), 
new Region(206, 306, 88, 94, font), 
new Region(306, 306, 94, 94, font) 


> 
} 
} 
} 
namespace monogame.Objects 
{ 
public class Region 
{ 
SpriteFont font; 
public Region(int x, int y, int width, int height, SpriteFont font) 
{ 
this.font = font; 
} 
} 
} 


Para a definição da posição da string dentro da região, por ora, 
vamos manter em x + width/2 @ y + height/2: 


namespace GameContent.Test 


{ 
[TestFixture()] 
public class RegionTest 
{ 
[TestFixtureSetUp()] 
public void SetUpRegion() 
{ 
SpriteFont font = null; 
region = new Region(10, 15, 20, 35, font); 
} 
[Test()] 
public void IsStringPositionVectorCentered() 
{ 
Assert.That(region.StringPosition, Is.EqualTo(new Vector2(20, 
32))); 
} 
} 
} 


A fim de resolver esse teste, a implementação em Region.cs pode 
ser a seguinte: 


public int State { get; set; } 

public Rectangle Area { get; set; } 

public Vector2 StringPosition { get; set; } 
SpriteFont font; 


public Region(int x, int y, int width, int height, SpriteFont font) 
{ 

State = @; 

Area = new Rectangle(x, y, width, height); 

this.font = font; 

StringPosition = new Vector2(Area.X + Area.Width/2, Area.Y + 
Area.Height / 2); 


} 


Agora precisamos desenhar o que falta na tela. Vamos mudar 
Board.cs da seguinte maneira: 


public void Draw(SpriteBatch sb) 


{ 
foreach (Rectangle line in lines) { 
sb.Draw(GeneralAttributes.LineTexture, line, Color.White); 
} 
DrawRegions(sb); 
} 
public void DrawRegions(SpriteBatch sb) 
{ 
foreach (Region region in regions) 
{ 
region.Draw(sb); 
} 
} 


E O regions.Draw() deve desenhar a string: 


public void Draw(SpriteBatch sb) 
{ 
sb.DrawString(font, GetSymbol(), StringPosition, Color.Black); 


} 


É importante incluir o arquivo de spriteront NO content . Uma forma 
é utilizando O monogame Pipeline Tool OU incluindo o seguinte arquivo 
dentro da pasta content (é necessário dar build pelo pipeline): 


<?xml version="1.0" encoding="utf-8"?> 
<XnaContent 
xmlns:Graphics="Microsoft.Xna.Framework.Content.Pipeline.Graphics"> 
<Asset Type="Graphics:FontDescription"> 
<FontName>Arial</FontName> 
<Size>34</Size> 
<Spacing>0</Spacing> 
<UseKerning>true</UseKerning> 
<Style>Regular</Style> 
<!-- <DefaultCharacter>*</DefaultCharacter> --> 
<CharacterRegions> 
<CharacterRegion> 
<Start>&H32;</Start> 
<End>&H126;</End> 


</CharacterRegion> 
</CharacterRegions> 
</Asset> 
</XnaContent> 


Alterando o estado (propriedade state ) das regions para 1, obtemos 
a seguinte imagem: 


x |X [x 


Figura 10.1: Board com a configuração atual de posição (div 2) 


Se mudarmos a posição da string de x + width/2 € y + height/2 para 
x + width/3 € y + height/3 , obtemos uma melhora significativa: 


x {X | x 


Figura 10.2: Board com a configuração de posição dividida por 3 


Essa melhora envolve corrigir os testes e o código: 


//RegionTest 
[Test()] 
public void IsStringPositionVectorCentered() 


{ 
Assert.That(region.StringPosition, Is.EqualTo(new Vector2(16, 26))); 


//Region 
public Region(int x, int y, int width, int height, SpriteFont font) 
{ 

State = ®ð; 

Area = new Rectangle(x, y, width, height); 

this.font = font; 

StringPosition = new Vector2(Area.X + Area.Width / 3, Area.Y + 
Area.Height / 3); 
} 


10.2 Atualizando o estado no Game Loop 


Neste momento, também precisamos interagir visualmente com as 
regiões e, para fazer isso, precisamos atualizar os estados do 
mouse e do ciclo de jogo no Board public void Update(GameTime time) . 
Será necessário um método que atualize o mouse dentro do update . 
Podemos testar o update passando o argumento newstate : 


namespace monogame.Testes.Handlers 
{ 

[TestFixture() ] 

public class StateManagerTest 


{ 
[Test()] 
public void UpdateBoardMouseStates() 
{ 
currentState = new MouseState(250, 250, @, 
ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released); 
MouseState newState = new MouseState(666, 666, ®, 
ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, ButtonState.Released, 
ButtonState. Released) ; 
gameBoard.Current = currentState; 
gameBoard.Previous = previousState; 
gameBoard.UpdateMouse(newState) ; 
Assert. That(gameBoard.Current, Is.EqualTo(newState) ); 
Assert.That(gameBoard.Previous, Is.EqualTo(currentState) ) ; 


} 


Para resolver essa implementação, podemos fazer as seguintes 
mudanças: 


using Microsoft.Xna.Framework. Input; 


namespace monogame.Objects 


{ 
public class Board 
{ 
public MouseState Current { get; set; } 
public MouseState Previous { get; set; } 
public void UpdateMouse(MouseState newState) 
{ 
Previous = Current; 
Current = newState; 
} 
} 
} 


Agora precisamos de algumas alterações para que tudo faça 
sentido. A primeira delas seria deixar o mouse visível e, para isso, 
sugiro deixar o parâmetro IsMousevisible = true; No construtor de 
Game1 . Além disso, o método updateMouse deve ser chamado dentro 
de um método update em Board , conforme a seguir: 


public class Board 


{ 
public void Update(GameTime gameTime) 
{ 
UpdateMouse(Mouse.GetState()); 
} 
} 


Ainda precisamos de mais algumas mudanças para podermos 

interagir com nosso jogo. Uma delas é declarar BoardstateManager NO 
Gamei.cs . Outra é ter acesso aos métodos updateClickedRegionState € 
clickedRegion de forma estática para que eles possam ser chamados 


a partir de Board sem haver necessidade de acoplar um objeto ao 
outro. As mudanças são as seguintes: 


public class Game1 : Game 


{ 
BoardStateManager stateManager; 
protected override void LoadContent() 
{ 
spriteBatch = new SpriteBatch(GraphicsDevice); 
stateManager = new BoardStateManager(); 
font = Content.Load<SpriteFont>("font"); 
board = new Board(font); 
} 
} 


//stateManager.FunctionCall() -> BoardStateManager.StaticFunctionCall() 
namespace monogame.Testes.Handlers 
{ 

[TestFixture() ] 

public class StateManagerTest 


{ 


[TestFixtureSetUp()] 
public void StateManagerSetUp() 
{ 
SpriteFont font = null; 
gameBoard = new Board(font); 
stateManager = new BoardStateManager(); 
previousState = new MouseState(250, 250, 0, 
ButtonState.Released, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 


[Test()] 
public void MouseClickedRegion4() 


{ 
currentState = new MouseState(250, 250, @, 


ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 


Assert. That (BoardStateManager.ClickedRegion(gameBoard.regions, 
currentState, 


previousState), Is.EqualTo(4)); 
} 


[Test()] 
public void MouseClickedRegion@() 
{ 
currentState = new MouseState(105, 105, @, 
ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released) ; 


Assert. That (BoardStateManager.ClickedRegion(gameBoard.regions, 
currentState, previousState), Is.EqualTo(@)); 


} 


[Test()] 
public void ClickIsOutsideRegions() 
{ 
currentState = new MouseState(50, 50, @, 
ButtonState.Pressed, ButtonState.Released, 


ButtonState.Released, ButtonState.Released, ButtonState.Released); 


Assert.That(BoardStateManager .ClickedRegion(gameBoard.regions, 
currentState, previousState), 
Is.EqualTo(-1)); 


[Test()] 
public void ClickInSeparatorLinesRetunsNegative() 


{ 
currentState = new MouseState(196, 101, @, 


ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 


Assert. That (BoardStateManager.ClickedRegion(gameBoard.regions, 
currentState, 


previousState), Is.EqualTo(-1)); 
} 


[Test()] 
public void ClickedRegionHasChangedState() 
{ 
currentState = new MouseState(250, 250, @, 
ButtonState.Pressed, ButtonState.Released, 
ButtonState.Released, 
ButtonState.Released, ButtonState.Released); 
var idx = 
BoardStateManager.ClickedRegion(gameBoard.regions, currentState, 
previousState); 


BoardStateManager.UpdateClickedRegionState(gameBoard.regions, idx); 
Assert.That(gameBoard.regions[4].State, Is.EqualTo(1)); 


} 


O teste para atualizar o estado após diferentes interações pode ser 
o seguinte: 


namespace monogame.Testes.Handlers 


{ 
[TestFixture()] 


public class StateManagerTest 
{ 


[Test()] 
public void RegionHasBeenClickedWithCorrectPlayers() 


{ 
Assert.That(gameBoard.regions[0].State, Is.EqualTo(0)); 


Assert.That(gameBoard.regions[1].State, Is.EqualTo(@)); 


gameBoard.UpdateCLicks(0); 
gameBoard.UpdateCLicks(1); 
Assert.That(gameBoard.regions[0].State, Is.EqualTo(1)); 
Assert.That(gameBoard.regions[1].State, Is.EqualTo(-1)); 


} 
Assim, a solução final passa a ser: 


namespace monogame.Objects 


{ 


public class Board 


{ 


public void Update(GameTime gameTime) 
{ 
UpdateMouse(Mouse.GetState()); 
UpdateCLicks(BoardStateManager.ClickedRegion(regions, 
Current, Previous)); 


} 
public void UpdateCLicks(int idx) 
{ 
BoardStateManager .UpdateClickedRegionState(regions, idx); 
} 


} 
O último toque seria adicionar O board.Update €M Game1 : 


protected override void Update(GameTime gameTime) 
{ 
if (GamePad.GetState(PlayerIndex.One).Buttons.Back == 
ButtonState.Pressed || Keyboard.GetState().IsKeyDown(Keys.Escape) ) 
Exit(); 


board.Update(gameTime) ; 
base.Update(gameTime) ; 


Vale lembrar que os métodos dentro do ciclo do jogo update/Draw 

são bastante complexos de testar. Mockar nossos testes traria 
poucas vantagens para o método praw , especialmente. Nosso 
método update poderia testar os impactos de todo o contexto se 
utilizássemos NSubstitute para O BoardStateManager , Mas ainda 
teríamos problemas para testar o mouse.Getstate() por não podermos 
estendê-lo de uma interface. Seria muito interessante aplicarmos 
esses testes, mas nosso framework já nos garante uma segurança 
nesse sentido. 


Se jogarmos nosso jogo agora, perceberemos que clicamos nas 
regiões mas nunca ganhamos. Ainda devemos implementar uma 
solução para determinar quem venceu. 
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Figura 10.3: Jogo até o momento 


10.3 Vamos ganhar este jogo! 


O que precisamos agora é uma forma de vencer o jogo e, quem 
sabe, sinalizar a vitória. Portanto, precisamos validar se linhas, 
colunas ou diagonais fecharam a condição de vitória. Para testar 
isso, vamos começar com as linhas, testando se cada linha está 
anunciando vitória corretamente. Vamos começar com um teste 
dizendo que, se todas as regiões têm estado e, a vitória é falsa: 


using NUnit.Framework; 
using System; 
using monogame.Objects; 


namespace monogame.Testes.Handlers 


{ 


[TestFixture()] 
public class WinStateManagerTest 
{ 
Region[] regions; 
[TestFixtureSetUp()] 
public void TestSetup() 
{ 


regions = new Region[9] { 
new Region(100, 100, 94, 94, null), 
new Region(206, 100, 88, 94, null), 
new Region(306, 100, 94, 94, null), 
new Region(100, 206, 94, 88, null), 
new Region(206, 206, 88, 88, null), 
new Region(306, 206, 94, 88, null), 
new Region(100, 306, 94, 94, null), 
new Region(206, 306, 88, 94, null), 
new Region(306, 306, 94, 94, null) 

>; 


[Test()] 
public void AllRegionsWith@NoVictoryPlayer() 


{ 
Assert.That(WinStateManager.WhichPlayerWon(regions), 


Is.EqualTo(0)); 


} 


{ 


} 


A melhor solução possível para esse teste é a seguinte: 


namespace monogame.Objects 


public class WinStateManager 


public static int WhichPlayerWon(Region[] regions) 
{ 


return ð; 


} 
E um bom próximo teste seria: 


[Test()] 
public void RowlHasWonP1() 
{ 
regions[0].State = 1; 
regions[1].State = 1; 
regions[2].State = 1; 
Assert.That (WinStateManager .whichPlayerWon(regions), 
Is.EqualTo(1)); 


} 


Que pode ser grosseiramente resolvido com alerta de refactor! : 


public static int WhichPlayerWon(Region[] regions) 
{ 
return (regions[0].State == 1 && regions[1].State == 1 && 
regions[2].State == 1) 
? 1 
: ð; 
} 


E se tentarmos algo assim? 


[Test()] 
public void Row2HasWonP2() 
{ 
TestSetup(); 
regions[3].State = -1; 
regions[4].State = -1; 
regions[5].State = -1; 
Assert. That (WinStateManager .whichPlayerWon(regions), Is.EqualTo(-1)); 


Para resolver esse problema, podemos pensar em uma solução 
grosseira, como: 


public static int WhichPlayerWon(Region[] regions) 
{ 

int row1 = HasWon(new int[] (0, 1, 2 }, new Region[] { regions[0], 
regions[1], regions[2] }); 

int row2 = HasWon(new int[] { @, 1, 2 }, new Region[] { regions[3], 
regions[4], regions[5] }); 

int row3 = HasWon(new int[] { ð, 1, 2 }, new Region[] { regions[6], 
regions[7], regions[8] }); 

return DetermineWinner(row1, row2, row3); 


public static int HasWon(int[] idx, Region[] regions) { 
return ((regions[idx[0]].State == 1 && regions[idx[1]].State == 1 && 


regions[idx[2]].State == 1) || (regions[idx[0]].State == -1 && 
regions[idx[1]].State == -1 && regions[idx[2]].State == -1)) 

? regions[@].State 

: ð; 
} 


public static int DetermineWinner(int row1, int row2, int row3) 


{ 
if (rowl != 0) 


{ 
return rowl; 
} 
else if (row2 != 0) 
{ 
return row2; 
} 
return row3; 
} 
} 


Este código está longe de ser maravilhoso, apenas fiz o mínimo 
necessário com os recursos que tenho (a versão antiga do .NET que 
roda MonoGame). Agora precisamos determinar quais colunas 


venceram. Para testar a primeira coluna podemos fazer o seguinte 
teste: 


[Test()] 

public void ColiHasWonP1() 

{ 
TestSetup(); 
regions[0].State = 
regions[3].State = 1; 
regions[6].State = 
Assert. That (WinStateManager .whichPlayerWon(regions), Is.EqualTo(1)); 
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} 


Para esse teste passar, precisamos de uma pequena mudança, 
como a seguinte: 


public static int WhichPlayerWon(Region[] regions) 


{ 

int row1 = HasWon( new Region[] { regions[0], regions[1], regions[2] 
})3 

int row2 = HasWon( new Region[] { regions[3], regions[4], regions[5] 
})3 

int row3 = HasWon( new Region[] { regions[6], regions[7], regions[8] 
})3 

int coli = HasWon(new Region[] { regions[0], regions[3], regions[6] 
})3 

return DetermineWinner(row1, row2, row3, col1); 
} 


public static int HasWon(Region[] regions) { 
return ((regions[@].State == 1 && regions[1].State == 1 && 


regions[2].State == 1) || (regions[@].State == -1 && regions[1].State == 
-1 && regions[2].State == -1)) 

? regions[@].State 

: ð; 
} 


public static int DetermineWinner(int row1, int row2, int row3, int coli) 


{ 
if (rowl != 0) 


{ 


return rowl; 


} 
else if (row2 != 0) 
{ 

return row2; 
} 
else if (row3 != 0) 
{ 

return row3; 
} 


return col1; 


} 


Agora podemos continuar tentando melhorar aquele código 
monstruoso, ou tentar uma nova solução com o seguinte teste: 


[Test()] 

public void Col2HasWonP2() 

{ 
TestSetup(); 
regions[1].State = -1; 
regions[4].State = -1; 
regions[7].State = -1; 


Assert. That (WinStateManager .whichPlayerWon(regions), Is.EqualTo(-1)); 
} 


Para este teste passar e evitar a evolução do monstro, podemos 
fazer um pequeno refactor. 


public static int WhichPlayerWon(Region[] regions) 
{ 


int[] axis = new int[] { 
HasWon( new Region[] { regions[0], regions[1], regions[2] }), 


}; 


HasWon(new 
HasWon (new 
HasWon (new 
HasWon (new 
HasWon(new 


Region[] { 
Region[] { 
Region[] { 
Region[] { 
Region[] { 


regions[3], 
regions[6], 
regions[0], 
regions[1], 
regions[2], 


foreach(int value in axis) { 


regions[4], 
regions[7], 
regions[3], 
regions[4], 
regions[5], 


regions[5] }), 
regions[8] }), 
regions[6] }), 
regions[7] }), 
regions[8] }) 


if (value == 1 || value == -1) { return value; } 


} 


return ð; 


public static int HasWon(Region[] regions) { 
return ((regions[0].State == 1 && regions[1].State == 1 && 


regions[2].State == 1) || (regions[@].State == -1 && regions[1].State == 
-1 && regions[2].State == -1)) 

? regions[0].State 

: ð; 
} 


Considerando a refatoração que acabamos de fazer, existe uma 
alternativa interessante. Essa outra forma seria um pouco mais ao 
estilo .neT , utilizando ling. O pseudocódigo a seguir é uma 
sugestão de como fazer isso: 


public static int WhichPlayerwon(Region[] regions) 


{ 
(from value in axis 
where value == 1 || value == -1 
select value).First(); 
} 


Agora falta testarmos diagonais. Somente dois pares sao 
adicionados aos testes, mas vamos fazer um de cada vez: 


[Test() ] 

public void DiagiHasWonP1() 

{ 
TestSetup(); 
regions[@].State = 1; 
regions[4].State = 1; 
regions[8].State = 1; 


Assert. That (WinStateManager .WhichPlayerWon(regions), Is.EqualTo(1)); 
} 


Para resolver isso, bastaria uma mudança em whichPlayerwon : 


public static int WhichPlayerwon(Region[] regions) 


{ 


} 


int[] axis = 


new int[] { 


HasWon( new Region[] { regions[0], regions[1], regions[2] }), 
Region[] { regions[3], regions[4], 


HasWon (new 
HasWon (new 
HasWon(new 
HasWon (new 
HasWon(new 
HasWon(new 


Region[] { 
Region[] { 
Region[] { 
Region[] { 
Region[] { 


regions[6], 
regions[0], 
regions[1], 
regions[2], 
regions[0], 


regions[7], 
regions[3], 
regions[4], 
regions[5], 
regions[4], 


regions[5] }), 
regions[8] }), 
regions[6] }), 
regions[7] }), 
regions[8] }), 
regions[8] }) 


}; 


foreach(int value in axis) { 
if (value == 1 || value == -1) { return value; } 


} 


return ð; 


E para a outra diagonal, adicionamos o seguinte teste: 


[Test()] 
public void Diag2HasWonP2() 


{ 


} 


TestSetup(); 

regions[2].State = -1; 
regions[4].State = -1; 
regions[6].State = -1; 


Assert.That (WinStateManager .WhichPlayerWon(regions), Is.EqualTo(-1)); 


Que adiciona mais uma linha à variável axis em whichPlayerhon : 


int[] axis = 


new int[] { 
HasWon( new Region[] { regions[@], regions[1], regions[2] }), 


HasWon(new 
HasWon (new 
HasWon (new 
HasWon (new 
HasWon(new 
HasWon(new 


Region[] { 
Region[] { 
Region[] { 
Region[] { 
Region[] { 
Region[] { 


regions[3], 
regions[6], 
regions[0], 
regions[1], 
regions[2], 
regions[0], 


regions[4], 
regions[7], 
regions[3], 
regions[4], 
regions[5], 
regions[4], 


regions[5] }), 
regions[8] }), 
regions[6] }), 
regions[7] }), 
regions[8] }), 
regions[8] }), 


HasWon(new Region[] { regions[2], regions[4], regions[6] }) 


}; 


Para testar o projeto até agora via linha de comando, é preciso fazer 


todo o build e rodar nunit-console 
monogame.Testes/bin/Debug/monogame.Testes.dll OU MONO IOMAP=all nunit- 


console monogame.Testes/monogame.Testes.csproj para pipelines. 


Agora conseguimos determinar qual jogador vence de acordo com 
todas as regras do jogo, mas ainda não vemos sinais de vitória ao 
jogar. Por isso, no próximo capítulo vamos tratar de dar os toques 
finais ao jogo. 


CAPÍTULO 11 
Vitória visual 


Conseguimos desenvolver praticamente toda a lógica do jogo, mas 
ainda faltam alguns detalhes importantes, como determinar quem 
venceu e bloquear interações futuras. Além disso, precisamos de 
alguns pequenos refactors. Utilizar o Analyzer do Visual Studio já 
será um bom primeiro passo. 


11.1 Análise e refatoração do código 


Existem diversas formas de refatorar um código, e temos feito isso 
toda vez que revisamos um código antigo, que já não parece 
necessário, ou um código repetido. O refactor que proponho para 
este capítulo é uma análise do estado do código. 


Para isso, no Mac, basta seguir a rota Project -> Analyze -> Whole 
Solution . À resposta que obteremos será semelhante à seguinte 
imagem: 







© OErrors Ñ 4 Warnings 65 Messages EM Build Output Q 
! Line Description File Project Path Category 

D 6 This class is recommended to be defined as static Regions.cs Handlers/Regions.cs Language Usage Opportunitie: 
® 5 This class is recommended to be defined as static Input.cs Handlers/Input.cs Language Usage Opportunitie: 
(i) 6 This class is recommended to be defined as static WinStateManager.cs monogame/Objects/WinStateManager.cs Language Usage Opportunitie: 
A 10 Redundant array creation expression WinStateManager.cs monogame/Objects/WinStateManager.cs Redundancies in Code 

o 28 Redundant comma in array initializer Board.cs monogame/Objects/Board.cs Redundancies in Code 

B 24 Remove the redundant size indicator Board.cs monogame/Objects/Board.cs Redundancies in Code 

i] 30 Remove the redundant size indicator Board.cs monogame/Objects/Board.cs 

(i) 50 Redundant 'else' keyword Region.cs monogame/Objects/Region.cs 

ri) 18 eae Ro ‘Gamot.stotonianager can be removed as the value Gamet.cs monogame/Gamei.cs 

A 43 Parameter 'gameTime' is never used Board.cs monogame/Objects/Board.cs 

A 7 Parameter 'args' i: ed Main.cs monogame/Main.cs 

A 81 Redundant array creati BoardConfig.cs monogame.Testes/Objects/BoardConfig.cs 

Q 10 Parentheses are redund: ribute has no arguments BoardConfig.cs monogame.Testes/Objects/BoardConfig.cs 

KE] 15 Parentheses are redundant if attribute has no arguments BoardConfig.cs monogame.Testes/Objects/BoardConfig.cs 

o 22 Parentheses are redundant if attribute has no arguments BoardConfig.cs monogame.Testes/Objects/BoardConfig.cs 

0 28 Parentheses are redundant if attribute has no arguments BoardConfig.cs monogame.Testes/Objects/BoardConfig.cs 





Figura 11.1: Resultado da análise de código 


Meus erros warnings: 


e Warning: construção de arrays 
e Warning: variáveis não utilizadas 


Se formos ao código, podemos ver que a mudança sugerida é a 
seguinte: 


//Antes WinStateManager.cs 


int[] axis = 


new int[]( 


HasWon( new Region[] { regions[0], regions[1], regions[2] 3), 


HasWon(new Region[] { regions[3], regions[4], regions[5] 3), 
HasWon(new Region[] { regions[6], regions[7], regions[8] }), 
HasWon(new Region[] { regions[0], regions[3], regions[6] }), 
HasWon(new Region[] { regions[1], regions[4], regions[7] }), 
HasWon(new Region[] { regions[2], regions[5], regions[8] }), 
HasWon(new Region[] { regions[0], regions[4], regions[8] }), 
HasWon(new Region[] { regions[2], regions[4], regions[6] }) 

}; 

//Depois 

int[] axis = { 
HasWon(new Region[] { regions[0], regions[1], regions[2] }), 
HasWon(new Region[] { regions[3], regions[4], regions[5] 3), 
HasWon(new Region[] { regions[6], regions[7], regions[8] 3), 
HasWon(new Region[] { regions[0], regions[3], regions[6] }), 
HasWon(new Region[] { regions[1], regions[4], regions[7] }), 
HasWon(new Region[] { regions[2], regions[5], regions[8] }), 
HasWon(new Region[] { regions[0], regions[4], regions[8] }), 
HasWon(new Region[] { regions[2], regions[4], regions[6] }) 


}; 


Podemos, inclusive, ver que a linha seguinte à declaração int[] axis 


= {...} pode ser refatorada devido à sua simplicidade para 
foreach(int value in axis) if (value == 1 || value == 


+. O próximo ponto é que gameTime nunca é utilizado e, por isso, 
podemos retirá-lo da chamada da função: 


//Antes Board.cs 
public void Update(GameTime gameTime) 


{ 


-1) { return value; 


//Depois 
public void Update() 
{ 


} 


Importante! Não se esqueça de corrigir o método update em 


Gamei.cs. 


Toda vez que modificamos o nosso código é importante acompanhar 
os testes automatizados para verificar se não quebramos alguma 
coisa nova. Depois de verificar que nossos testes ainda estão 
passando, podemos continuar analisando os outros erros que temos 
do Analyzer , COMO: 


e Transformar classes em static. 

e Corrigir a forma como declaramos arrays (declarar sem new ... 
e retirar O size da declaração, como fizemos para O int[] axis 
= {...}). 

e Não utilizar () em chamadas de anotações quando não 
possuem argumentos (basta utilizar [Test] em vez de [Test()], 
inclusive para aumentar a legibilidade). 

e A classe teste Regiontest possui duas variáveis não mais 
utilizadas. Identifique-as no analyzer e sinta-se livre para 
deletá-las. 


As classes estáticas já possuem todos os seus métodos estáticos, 
por isso o resultado é o seguinte: 


public static class Regions; 
public static class Input; 
public static class WinStateManager ; 


Agora que demos uma boa refatorada podemos seguir para 
efetivamente ver a vitória. 


11.2 Vitória visual 


Uma das coisas que podemos fazer é criar uma função que 
simplesmente gerará uma string com o jogador vencedor, então 
bastará imprimir isso na tela. Esse cenário pode começar com o 
WinStateManager , para O qual temos duas soluções possíveis: 


1. Definir uma variável que guarde o vencedor durante O update e, 
no Draw, Chamar essa variável. 
2. A decisão de qual player venceu é feita no Draw. 


O primeiro método parece o mais adequado, pois estamos 
diferenciando a lógica de update da lógica de Draw. Assim, um teste 
poderia ser: 


[Test] 
public void NoPlayerHasWon() 


{ 
TestSetup(); 


Assert. That(WinStateManager.PlayerWhoWon, Is.EqualTo("")); 
} 


Ele é facilmente resolvido com: 


public static class WinStateManager 


{ 
public static string PlayerWhoWon = ""; 


Agora podemos checar se temos um vencedor quando o jogo foi 
vencido: 


[Test] 

public void PlayeriHasWonMessage() 

{ 
TestSetup(); 
regions[0].State = 
regions[4].State = 1; 
regions[8].State = 1; 
WinStateManager .Update(regions); 


I 
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Assert.That (WinStateManager.PlayerwhoWon, Is.EqualTo("P1 Wins")); 
} 


Temos o método update em winStateManager , que é capaz de 
resolver nosso código da seguinte maneira: 


public static void Update(Region[] regions) 
{ 


var whoWon = WhichPlayerWon(regions) ; 
if (whoWon == 1) { PlayerWhoWon = "P1 Wins"; 3 
} 


Agora o ultimo teste para determinar o player vencedor: 


[Test] 
public void Player2HasWonMessage() 
{ 
TestSetup(); 
regions[4].State = -1; 
regions[5].State = -1; 


regions[6].State = -1; 
WinStateManager .Update(regions) ; 
Assert. That (WinStateManager.PlayerwhoWon, Is.EqualTo("P2 Wins")); 


} 
Para solucionar isso basta adicionar um novo if: 


public static void Update(Region[] regions) 


{ 
var whoWon = WhichPlayerWon(regions) ; 
if (whoWon == 1) { PlayerWhoWon = "P1 Wins"; 3 
if (whoWon == -1) { PlayerWhoWon = "P2 Wins"; } 
} 


Assim, quando O WinStateManager .Update(regions) é chamado no 
Update de Board, podemos ter a string com o campeão retornada. 
Para isso, podemos adicionar o método 
WinStateManager.Update(regions) aO Board : 


namespace monogame.Objects 


{ 


public class Board 


public void Update() 
{ 
if (WinStateManager.CankeepPlaying) 


{ 
UpdateMouse(Mouse.GetState()); 


UpdateCLicks(BoardStateManager.ClickedRegion(regions, 
Current, Previous) ); 
WinStateManager.Update(regions) ; 


Implementando feedbacks visuais 


Para termos o feedback visual, precisamos que o método Draw 
escreva a vitória no Board: 


using Microsoft.Xna.Framework; 
using Microsoft.Xna.Framework.Graphics; 
using Microsoft.Xna.Framework. Input; 


namespace monogame.Objects 


{ 


public class Board 


{ 
const int BASE_INVERT_AXIS = 100; 


public SpriteFont font { get; set; + 


public Board(SpriteFont font) 
{ 


this.font = font; 


public void Draw(SpriteBatch sb) 
{ 


foreach (Rectangle line in lines) 


{ 


sb.Draw(GeneralAttributes.LineTexture, line, 
Color.White); 


} 
DrawRegions(sb); 
DrawWinner(sb); 


} 


public void DrawWinner(SpriteBatch sb) 


sb.DrawString(font, WinStateManager.PlayerWhoWon, 


new Vector2(410, 100), 
Color.DarkBlue) ; 


} 


11.3 Bloqueio do jogo apos o fim 


A ultima coisa que podemos fazer para o jogo ficar perfeito é criar 
uma forma de bloquear movimentos futuros de ambos os players. 
Para isso, criaremos outra variável auxiliar, CankeepPlaying , na classe 
WinStateManager que nos dirá se O update de Board deve atualizar 
seu conteúdo: 


[Test] 
public void KeepPlayingWhenNoPlayerWon() 


{ 
TestSetup(); 


WinStateManager .Update(regions); 
Assert.That (WinStateManager.CankKeepPlaying, Is.EqualTo(true)); 
} 


Neste momento, basta fazer o seguinte: 


public static class WinStateManager 


{ 


public static string PlayerWhoWon = ""; 
public static bool CanKeepPlaying = true; 


} 
Então, precisamos de um teste para "p1 wins" e para "P2 wins": 


[TestCase(1)] 
[TestCase(-1)] 
public void CantKeepPlayingWhenNoPlayerWon(int x) 


{ 

TestSetup(); 

regions[0].State = x; 

regions[4].State = x; 

regions[8].State = x; 

WinStateManager .Update(regions); 

Assert. That (WinStateManager.CanKeepPlaying, Is.EqualTo(false)) ; 
} 


Para que esses testes passem, primeiramente precisamos de uma 
pequena correção no testsetup : 


[TestFixtureSetUp] 
public void TestSetup() 


{ 


WinStateManager.CanKeepPlaying = true; 
WinStateManager.PlayerWhoWon = ""; 
} 


Em winstateManager , precisamos modificar o método update : 


public static void Update(Region[] regions) 


{ 
var whoWon = WhichPlayerWon(regions) ; 
if (whoWon == 1) { PlayerWhoWon = "P1 Wins"; CanKeepPlaying = false; + 
if (whoWon == -1) { PlayerWhoWon = "P2 Wins"; CanKeepPlaying = false; 
} 
} 


Agora precisamos de uma verificação em Board.Update para impedir 
que ocorra O update caso alguém tenha ganhado: 


public void Update() 


{ 
if (WinStateManager.CanKeepPlaying) 


{ 
UpdateMouse(Mouse.GetState()); 
UpdateCLicks(BoardStateManager.ClickedRegion(regions, Current, 
Previous) ); 
WinStateManager .Update(regions); 
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Figura 11.2: Vitória do Player 1 
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Figura 11.3: Vitória do Player 2 


Agora que entendemos como a mecanica basica de testes funciona 
com um framework simples, podemos começar a adaptar esses 
conceitos dentro de uma engine, a Unity, que provavelmente vai 
ajudar a garantir que seus jogos tenham qualidade de código. 
Vamos aprender desde coisas como manipular inputs do usuário de 
forma testável até movimentação e interação com outros objetos. 


Testando com Unity 


CAPÍTULO 12 
Introdução a testes com engines 


É muito legal saber que podemos fazer testes com frameworks 
famosos de desenvolvimento de game e inclusive aplicar fluxos de 
TDD neles, embora essa não seja a realidade para a maior parte 
dos jogos desenvolvidos com tais frameworks, infelizmente. 


Na parte anterior, aprendemos a testar jogos que utilizam o 
MonoGame, talvez o maior framework do mercado. Agora podemos 
expandir o conceito de testes para quase todos os outros 
frameworks de games, como Raylib (para todos seus 500 milhões 
de portes), Pygame, libGDX, Phaser e ggez. 


Existem também algumas engines que nos permitem utilizar 
recursos de testes da linguagem para fazermos testes bem legais, 
mesmo que necessitemos de alguns hacks para isso (alguns 
exemplos dessas engines sao Amethyst, Godot, Panda3D, 
AppGamekKit e jMonkey), mas quando falamos das maiores engines 
do mercado, como Unity, Unreal e CRYENGINE, não costuma ser 
tão simples. 


Felizmente, a Unity lançou em sua quarta versão, muitos anos atrás, 
um pacote chamado Unity Test Tools 
(https://github.com/spe3d/unitytesttools), que hoje foi deprecado e 
incluído no Unity Test Runner incorporado à engine. Um rest 

Runner é basicamente um executor de todos os testes. 


A história dos testes na Unity 


A história por trás dos motivos pelos quais a Unity incluiu um 
sistema de testes em sua engine é interessante. Segundo 
Tomek Paszek, as pessoas que desenvolviam a Unity usavam 
testes unitários para garantir a estabilidade da engine. Então ele 
assumiu a responsabilidade de criar o pacote Unity Test Tools. 


No que se refere a TDD, encontramos muitas referências, como 
no link a seguir, para desenvolvermos games na Unity: 
https://blogs.unity 3d.com/2018/11/02/testing-test-driven- 
development-with-the-unity-test-runner/? 
_ga=2.126975821.1733404120.1562524133- 
129453552.1556817337. E interessante também dar mais uma 
olhada no pacote de testes NUnit, que é um pacote usado pela 
Unity: https://github.com/nunit/docs/wiki/NUnit-Documentation. 





Nesta parte, vamos desenvolver um jogo simples que nos permite 
movimentar um player enquanto inimigos aparecem aleatoriamente 
ao redor do nosso componente. A cada colisão perdemos uma vida 
e, quando ela chegar a zero, nosso player morre. 


12.1 Configurando os testes 


Agora que sabemos um pouco da história dos testes na Unity, 
podemos começar a entender como configurá-los. Essa parte é um 
pouco mais complicada e também pode variar bastante com a 
versão da Unity que se está usando. Para as versões 2018 e 2019 
da Unity esta configuração é a recomendada. 


Na Unity existem dois tipos de anotações de teste: a [UnityTest] ea 
[Test] . A diferença é que a UnityTest pode rodar em PlayMode € 
permite fazer verificações sobre ações, enquanto a Test funciona 


somente para funções independentes do ambiente do jogo. O passo 
a passo a seguir pode ser bem repetitivo e bobo, mas, como existe 
a possibilidade de variar a configuração conforme a versão, vamos 
passar rapidamente pelos passos mais comuns: 


1. Abra a Unity (estou usando a 2018.3.12) e faça login se 
necessário. 


2. Crie um novo projeto clicando em New. 


3. Dê um nome ao seu projeto (o meu chamei de TDD) e depois 
selecione o template visual 3D. E sempre mais fácil começar a 
brincar no modo 3D. 


4. Clique em Create Project. 


5. Para encontrar o Test Runner, basta seguir o caminho window > 


General > Test Runner. 


Test Runner 008 





PlayMode MLE 
| Run All | Run Selected | Rerun Failed 


a Nothing rT} voj ©0| Oo | 





~~. No tests to show 
L: ! ) EditMode tests can be in Editor only Assemblies, either in the editor special folder or Editor only Assembly Definitions with added Unity References "Test 
=œ Assemblies". 


Create EditMode Test Assembly Folder 
Ay EditMode test scripts can only be created in editor test assemblie 


Create Test Script in current folder 








Figura 12.1: O Test Runner 


6. Em um primeiro momento, seu Test Runner deve estar vazio, ja 
que nenhum cenário de teste foi configurado. Para isso, podemos 


clicar no botão create EditMode Test Assembly folder € a OPGAO Create 
Test Script in current folder aparecera. 


“Test Runner (SS 
PlayMode EZ iiO 
I Run All | Run Selected | Rerun Failed 


a Nothing =| voj @0} Oo 


Create Test Script in current folder 








Figura 12.3: Create Test Script in current folder 


PlayMode SEZ. iine 
| Run All | Run Selected | Rerun Failed 


q ©) Nothing =| yol Qo| Oo 











No tests to show 
(1) EditMode tests can be in Editor only Assemblies, either in the editor special folder or Editor only Assembly Definitions with added Unity References "Test 
Assemblies". 


l Create EditMode Test Assembly Folder 


A EditMode test scripts can only be created in editor test assemblies. 











| Create Test Script in current folder 





Figura 12.2: Create EditMode Test Assembly folder 


7. Quando abrimos O Test Assembly File dentro da pasta Tests 
criada, podemos perceber algumas soluções padrões definidas. As 
mais importantes são Unity References > Test Assemblies -> true € aS 
plataformas nas quais queremos que os testes sejam validados. 
Isso é importante se houver testes que podem quebrar de uma 
plataforma para a outra. 


a Tests Import Settings Jo 
(Open ) 


Allow 'unsafe' Code [|] 
Auto Referenced A 
Override References [|] 


Test Assemblies A 


Predefined Assemblies (Assembly—CSharp.dll 
C1) etc) will not reference this assembly. 

This assembly will only be used for tests and 

will not be included in player builds. 





Any Platform 


Include Platforms 
Android 

Editor 

iOS 

Linux 32-bit 
Linux 64-bit 
Linux Universal 


UOUU8U O 


Figura 12.4: Test Assembly File 


8. Para correr os testes, basta abrir o Test Runner e apertar o botão 
Run All no canto superior esquerdo. 


| Run All | Run Selected | Rerun Failed 
a oy 
| Nothir 








v “TDD 
Y v Tests.dll 
v v Tests 
Y vy NewTestScript 
v NewTestScriptSimplePasses 
w’ NewTestScriptWithEnumeratorPasses 


Figura 12.5: Run All 


9. Se abrirmos o arquivo gerado pelo Create Test Script in current 
folder , veremos as seguintes características: os dois frameworks 
para utilizar testes, using NUnit.Framework; © using 
UnityEngine.TestTools; ; a anotação [Test], que deve ser utilizada 
com a classe Assert para testar condições; a anotação [UnityTest], 
que deve ser utilizada com a classe assert para testar condições, 
mas podemos utilizar yield return null para pular um frame. Esses 
testes devem ser do tipo IEnumerator . 


using System.Collections; 

using System.Collections.Generic; 
using NUnit.Framework ; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class NewTestScript 


{ 
[Test] 


public void NewTestScriptSimplePasses() 


// Use the Assert class to test conditions 


[UnityTest] 
public IEnumerator NewTestScriptWithEnumeratorPasses() 


{ 


// Use the Assert class to test conditions. 
// Use yield to skip a frame. 
yield return null; 


} 


10. A Unity entrega os resultados dos testes em um XML igual ao do 
NUnit (https://github.com/nunit/docs/wiki/Test-Result-XML-Format). 


11. Para criar um novo arquivo de testes, podemos ir em Assets > 
Create > Testing > C# Test Script. 


12. Podemos utilizar a anotação unityPlatform para definir o Sistema 
Operacional de editores objetivos como [unityPlatform 
(RuntimePlatform.WindowsPlayer)] OU para excluir [UnityPlatform(exclude 
= new[] {RuntimePlatform.WindowsEditor })]. 


13. Caso você queira testar logs, a Unity possui asserts de log como 
O LogAssert.Expect(LogType.Log, "Log message"); 


14. Podemos criar um script CH em Assets > Scripts > PlayerWorks.cs . 
Criei o método public bool IsAvlive() { return false; } para que 
possamos testar no nosso script de testes. Se tentarmos utilizar um 
using para incorporar o teste, veremos que não funcionará. 


15. Para funcionar, precisamos criar um assembly Definition dentro 
da pasta Scripts. Chamei meu assembly Definition de player. O 
Assembly Definition define as relações para arquitetar a construção 
dos binários. A imagem a seguir mostra como criar: 






IGOLITI 
Playables 

Assembly Definition 
TextMeshPro 





2 Audio 










Scene 
Prefab Variant 






Audio Mixer 













Material 
Lens Flare 
Render Texture 






Reveal in Finder 
Open 





Figura 12.6: Scripts Assembly Definition 


16. No Assembly Definition de testes, devemos linkar o Assembly de 
player NO Campo Assembly Definition References . Aplique as 
mudanças. 


Assembly Definition References 


'— Player à Player © | 
a 


Figura 12.7: Referéncia ao Assembly Definition de player 


17. Criamos o seguinte teste com o objetivo de somente verificar se 
O player Criado possui o método Isalive (está vivo) retornando 
true , com uma implementação para compilar logo a seguir. 
Rodamos na Unity e obtemos um teste falhando: 


[Test] 
public void NewTestScriptSimplePasses() 


{ 


var player = new PlayerWorks(); 


Assert.AreEqual(true, player.IsAlive()); 
} 


public class PlayerWorks : MonoBehaviour 


{ 


public bool IsAlive() { return false; } 





v TDD 
v GTests.dll 
v GTests 
vw © NewTestScript 
© NewTestScriptSimplePasses 
w NewTestScriptWithEnumeratorPasses 


Figura 12.8: Teste falhando 


18. Fazemos o método IsAlive retornar true e todos os testes 
voltam a passar. 


Depois de todos esses passos, entendemos melhor como executar 
testes na Unity. Sabemos criar repositórios de testes e como 
conectar os repositórios feitos. Entendemos quais anotações utilizar 
para definir testes com [unitytest] € [Test] e como testar logs e 
escrever testes básicos. No próximo capítulo, vamos aprender a 
testar a movimentação do nosso player. 


CAPITULO 13 
Testando entradas de keyboard 


No momento, temos as configurações prontas para podermos iniciar 
nosso fluxo de testes. Neste capítulo, vamos explorar como testar 
as interações via teclado, comumente chamadas de inputs. Para 
testarmos inputs de teclado de forma automatizada, não faz sentido 
esperarmos que alguém aperte os botões. Sendo assim, temos que 
encontrar uma forma de testá-los sem pessoas interagindo. 
Faremos isso realizando um refactor de um código usual de 
interação via teclado para que este código agora seja testável. 


A importância disso é possibilitar que você entenda como é a lógica 
de transformação de códigos existentes em códigos testáveis. Saber 
como desconstruir um script acoplado para que ele possa ser 
testável facilitará nossa compreensão de como desenvolver códigos 
testáveis no futuro. Assim, neste momento vou fugir um pouco da 
lógica do TDD. 


Vamos ver como seria uma cena básica nesse sentido: 


1. Crie uma cena com um plano e um cubo. Garanta que ambos, 
plano e cubo, possuam colliders e, para facilitar a visualização, 
utilize cores diferentes para o cubo e para o plano. 





Figura 13.1: Cena básica para nosso teste de inputs 


2. Ao cubo adicione um Rigidbody . Add Component -> Physics -> 
Rigidbody . 


' O Inspector > 


Physics 


Rigidbody 


























Figura 13.2: Adicionando um Rigidbody ao cubo 


3. Adicione um script de movecontroller (isso garante que o script 
está dentro da pasta script). Add Component -> New script -> <nome 


do script> -> Create and Add. O script a seguir é um exemplo sem 
testes para desconstruirmos. 





Figura 13.3: Adicionando um script MoveController ao cubo 


using UnityEngine; 


public class MoveController : MonoBehaviour 


{ 
public float speed = 20f; 


Rigidbody _rb; 


private void Start() 


{ 
_rb = GetComponent<Rigidbody>(); 


void Update() 
{ 


var h = Input.GetAxis("Horizontal"); 
var v = Input.GetAxis("Vertical"); 


float = h * speed * Time.deltaTime; 
float z = v * speed * Time.deltaTime; 


x< 
I 


_rb.MovePosition(transform. position + new Vector3(x, 0, z)); 


} 
} 


Pronto! Conseguimos mover o cubo nas direções x e z.O 
problema do nosso script são as funções das classes estáticas, pois 
não conseguimos definir seus valores de saída, como Input.GetAxis 
e Time.deltaTime . Para podermos começar a testar isso, precisamos 
de uma função que isole esses efeitos. n e v já estão isolados em 
variáveis que podemos passar como argumento, mas ainda falta 
Time.deltaTime . Para isso, podemos aplicar o padrão Humble object 
Pattern. 


HUMBLE OBJECT PATTERN 


Este padrão é normalmente utilizado em jogos quando 
necessitamos testar um componente que possui uma lógica não 


trivial, geralmente por ser derivada de um framework. No nosso 
caso, a Unity. Implementamos esse padrão retirando toda lógica 
do componente difícil de testar e a colocamos de forma que seja 
fácil de testar. 





Assim, nosso primeiro passo seria extrair Time.deltaTime para uma 
variável e criar uma função que calcule a velocidade por frame. Para 
isso, podemos escrever um teste adicionando um test script 
chamado TestMove.cs que testará a entrada de uma função chamada 
SpeedByFrame : 


using NUnit.Framework ; 
using UnityEngine; 
using UnityEngine.TestTools; 


namespace Tests 


{ 


public class TestMove 


{ 


MoveController moveController; 


[OneTimeSetUp] 
public void TestSetUp() 
{ 


moveController = new MoveController(); 


} 


[Test] 
public void TestMovePassesForHorizontalAxis() 


{ 
float h = 1f; 
float deltaTime = 1f; 


float actualSpeed = moveController.SpeedByFrame(h, deltaTime); 


Assert.AreEqual(actualSpeed, 20f); 


} 
} 
} 


Para esse teste passar, basta criarmos a função speedByFrame NO 
script movecontroller . Uma sugestão é começar com: 


float SpeedByFrame(float axis, float deltaTime) 
{ 


return speed; 


} 


Agora, sabemos que essa função não atenderá a toda nossa 
demanda, por isso adicionamos um novo teste com argumentos que 
necessitam ser combinados: 


// TestMove.cs 
[Test] 
public void TestMovePassesForVerticalAxis() 


{ 
float v = 0.3f; 


float deltaTime = @.7f; 
float actualSpeed = moveController.SpeedByFrame(v, deltaTime) ; 


Assert. That(Mathf.Approximately(actualSpeed, 4.2f)); 
} 


Para resolvermos isso, basta fazer o seguinte refactor: 


void Update() 

{ 
var h = Input.GetAxis("Horizontal"); 
var v = Input.GetAxis("Vertical"); 
var deltaTime = Time.deltaTime; 


float x 
float z 


SpeedByFrame(h, deltaTime); 
SpeedByFrame(v, deltaTime); 


“rb.MovePosition(transform.position + new Vector3(x, ©, Z)); 


} 
float SpeedByFrame(float axis, float deltaTime) 
{ 
return axis * speed * deltaTime; 
} 


Se você quiser utilizar recursos mais novos de C# na função 
SpeedByFrame , Sugiro utilizar funções Expression Body, assim: float 


SpeedByFrame(float axis, float deltaTime) => axis * speed * deltaTime; . 


Agora podemos pensar em uma forma de retornar para a nova 
posição do nosso cubo. Para isso, podemos usar a função 
CalculatePosition , que recebe uma position e duas variáveis de 
direção x e z. Nosso primeiro teste deve garantir que, se não há 
novas direções, a posição permanece a mesma: 


[Test] 
public void TestNewPositionHasNoChangeOverDirection() 


{ 
float x = Of; 


float z = Of; 
Vector3 position = new Vector3(3f, 4f, 5f); 


Vector3 newPosition = moveController.CalculatePosition(position, x, Z); 


Assert.AreEqual(position, newPosition) ; 


} 
Para esse teste passar, basta fazermos: 


public Vector3 CalculatePosition(Vector3 position, float x, float z) 


{ 


return position; 


} 


Mas queremos que ele se mova na direção x também, por isso 
escrevemos o teste com a seguinte solução: 


[Test] 
public void TestNewPositionHasChangedOnx() 


{ 
float x = 1f; 


float z = Of; 
Vector3 position = new Vector3(3f, 4f, 5f); 


Vector3 newPosition = moveController.CalculatePosition(position, x, z); 


Assert.AreEqual(new Vector3(4f,4f,5f) , newPosition) ; 
} 


public Vector3 CalculatePosition(Vector3 position, float x, float z) 


{ 


return position + new Vector3(x, ©, 0); 


} 


Por último, queremos que se mova na direção z também, assim 
adicionamos mais um teste: 


[Test] 
public void TestNewPositionHasChangedOnXAndZ () 


{ 
float x = 3f; 


float z = 5f; 
Vector3 position = new Vector3(3f, 4f, 5f); 


Vector3 newPosition = moveController.CalculatePosition(position, x, Z); 


Assert.AreEqual(new Vector3(6f, 4f, 10f), newPosition); 
} 


Com a solução final a seguir: 


void Update() 

{ 
var h = Input.GetAxis("Horizontal"); 
var v = Input.GetAxis("Vertical"); 
var deltaTime = Time.deltaTime; 


float x = SpeedByFrame(h, deltaTime); 
float z = SpeedByFrame(v, deltaTime); 


_rb.MovePosition(CalculatePosition(transform.position, x, z)); 


} 


public Vector3 CalculatePosition(Vector3 position, float x, float z) => 
position + new Vector3(x, O, z); 


Falando de Orientação a Objetos e de humble object pattern, 
poderíamos extrair as funções speedByFrame € CalculatePosition para 
um objeto movement que devemos, então, passar como atributo em 
MoveController . Não acredito que essa extração seja extremamente 
necessária, pois ela não será reaproveitada em outros locais e já 
temos uma ótima testabilidade da forma como estamos fazendo. De 
qualquer forma, segue um exemplo deste código: 


///TestMove.cs 
namespace Tests 


{ 


public class TestMove 


{ 


Movement movement; 


[OneTimeSetUp] 
public void TestSetUp() 
{ 
movement = new Movement(); 
} 
[Test] 
public void TestMovePassesForHorizontalAxis() 
{ 


float h = 1f; 

float speed = 20f; 

float deltaTime = 1f; 

float actualSpeed = movement.SpeedByFrame(h, speed, deltaTime) ; 


Assert.AreEqual(actualSpeed, 20f); 


[Test] 
public void TestMovePassesForVerticalAxis() 


{ 
float v = 0.3f; 


float speed = 20f; 
float deltaTime = Q.7f; 


float actualSpeed = movement.SpeedByFrame(v, speed, deltaTime) ; 


Assert.That(Mathf.Approximately(actualSpeed, 4.2f)); 


} 


/// Movement.cs 
using UnityEngine; 


public class Movement : MonoBehaviour 


{ 
public float SpeedByFrame(float axis, float speed, float deltaTime) => 


axis * speed * deltaTime; 


public Vector3 CalculatePosition(Vector3 position, float x, float z) => 
position + new Vector3(x, ©, z); 


} 


///MoveController.cs 
using UnityEngine; 


public class MoveController : MonoBehaviour 
{ 

public float speed = 20f; 

Movement movement; 

Rigidbody _rb; 


private void Start() 


{ 
_rb = GetComponent<Rigidbody>(); 


movement = new Movement(); 


void Update() 

{ 
var h = Input.GetAxis("Horizontal"); 
var v = Input.GetAxis("Vertical"); 
var deltaTime = Time.deltaTime; 


float x = movement.SpeedByFrame(h, speed, deltaTime) ; 
float z movement.SpeedByFrame(v, speed, deltaTime) ; 


_rb.MovePosition(movement.CalculatePosition(transform.position, x, 
Z)); 
} 
} 


Esta mudança pode ser encontrada na branch 
https://github.com/Game TDD/TDD-on-Unity/tree/Humble-Object- 


Pattern. 





Voltando ao código da master, poderíamos fazer uma última 
simplificação: 


///MoveController.cs 

void Update() 

{ 
float x = SpeedByFrame(Input.GetAxis("Horizontal"), Time.deltaTime) ; 
float z = SpeedByFrame(Input.GetAxis("Vertical"), Time.deltaTime) ; 


_rb.MovePosition(CalculatePosition(transform.position, x, z)); 


} 


E podemos corrigir um erro de boas praticas Unity no teste, 
mudando de movecontroller = new MoveController , ja que a Unity nao 
permite instanciar Scripts como Objetos, para: 


[OneTimeSetUp ] 
public void TestSetUp() 
{ 


moveController = new GameObject().AddComponent<MoveController>(); 


} 


13.1 Injeção de dependências 


Atualmente, conseguimos testar somente nossas funções, mas não 
conseguimos testar as interações do nosso cubo com o cenário, por 
exemplo, se ele de fato se move quando apertamos o 

Input .Getaxis ("Horizontal") . Para fazermos isso, precisamos 
encapsular nossas funções de classes estáticas em uma interface 
que podemos substituir em testes. Para isso, crie uma interface com 
métodos para abstrair Time.deltaTime € Input.Getaxis . Chamei minha 
interface de Iunityservice e declarei os métodos float GetDeltaTime() 
e float GetInputAxis(string axis). O resultado foi este: 


public interface IUnityService 


{ 
float GetDeltaTime(); 


float GetInputAxis(string axis); 
} 


Agora precisamos de uma classe que implemente Iunityservice, 
além disso, essa classe precisa ter os assets da Unity disponíveis. 
Então a implementação ficou assim: 


//UnityMoveService.cs 
using UnityEngine; 
using System.Collections; 


public class UnityMoveService : MonoBehaviour, IUnityService 
{ 
public float GetDeltaTime() => Time.deltaTime; 


public float GetInputAxis(string axis) => Input.GetAxis(axis) ; 


Agora precisamos que movecontroller possua um atributo que 
receba IUnityservice da seguinte forma: public IUnityService 
service; , € precisamos passar uma implementação de Iunityservice 
para service . Há três maneiras mais simples de se fazer isso: 


1. Criar um Gameobject que possua um componente com o script 
UnityMoveService . 

2. Criar um construtor para movecontroller que receba uma 
implementação de Iunityservice e passe essa implementação 
para a variável service. 

3. Verificar se service existe e, caso não exista, adicionar o script 
como novo componente. Isso seria o equivalente a if (service 
== null) {service = new UnityMoveService(); }. Sei que como boas 
práticas de C# isso é estranho, mas na sintaxe Unity isso é 
bastante comum. 


Assim, vamos definir a adição do script de uma forma simples: "Se 
ele não passar pelo método 1, adicione-o como componente”: 


public class MoveController : MonoBehaviour 


{ 
public IUnityService service; 


private void Start() 
{ 
_rb = GetComponent<Rigidbody>(); 
if (service == null) 
{ 
service = this.gameObject .AddComponent<UnityMoveService>(); 
} 
} 


void Update() 
{ 
float x = SpeedByFrame(service.GetInputAxis("Horizontal"), 
service.GetDeltaTime()); 
float z = SpeedByFrame(service.GetInputAxis("Vertical"), 
service.GetDeltaTime()); 


_rb.MovePosition(CalculatePosition(transform.position, x, z)); 


} 
} 
Incluindo testes de PlayMode 


Agora podemos começar a pensar em utilizar testes de PlayMode 
para verificar se nosso script está OK (eles são semelhantes a 
testes de integração), mas antes precisamos de uma biblioteca que 
nos ajude com Test Doubles, um mock que nos permite controlar os 
resultados. Antigamente, na Unity era bastante simples utilizar a 
DLL do NSubstitute, mas atualmente é um pouco complicado. 
Vamos utilizar a lib NSubstitute, e vou ensinar como descomplicar 
seu uso, mas você pode adicionar o asset Zenject, disponível na 
Asset Store, para utilizar outro framework de Test Doubles. 


NSUBSTITUTE 


Por conta da versão do Mono que a Unity utiliza, não podemos 
simplesmente baixar uma versão recente do NSubstitute. Para 
isso, precisamos da DLL versão 1.4.3 . O que eu fiz foi criar um 


novo projeto simples, executar o comando dotnet add <Nome do seu 
proj>.csproj package NSubstitute --version 1.4.3 e gerar O build do 
projeto. Depois disso, acessei a pasta dos testes de PlayMode e 
cliquei em Import new asset , escolhendo a DLL do NSubstitute do 
outro projeto. 





Agora que sabemos obter a DLL do NSubstitute, podemos criar 
testes de PlayMode. Para isso, precisamos criar na Unity a nova 
pasta de testes para PlayMode. Basta seguir os mesmos passos do 
capítulo anterior em configurando testes, mas em vez de edit mode 
vá até a aba play mode . Acesse PlayMode -> Create PlayMode Test 
Assembly Folder -> Create test script in current folder € depois, no 
arquivo de Test Assembly , adicione uma referência ao Assembly de 


Scripts. Com isso, chamamos nosso novo script de testes de 
PlayTestMoveController . Primeiro veremos o teste e depois 
entenderemos o que foi feito: 


using System.Collections; 

using System.Collections.Generic; 
using NUnit.Framework ; 

using NSubstitute; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class PlayTestMoveController 


{ 
[UnityTest] 
public IEnumerator PlayerMovesOnlyTowardsXDirection() 


{ 


var cube = new GameObject().AddComponent<MoveController>(); 
cube. gameObject .AddComponent<Rigidbody>() ; 


var service = Substitute. For<IUnityService>(); 
service.GetDeltaTime().Returns(0.3f); 


service.GetInputAxis("Horizontal").Returns(1f); 


cube.speed = 1f; 
cube.service = service; 


Vector3 initialPosition = cube.transform. position; 
cube. service.GetInputAxis ("Horizontal"); 


yield return new WaitForSeconds(@.25f) ; 
Vector3 finalPosition = cube.transform. position; 


Assert.That(finalPosition.x > initialPosition.x); 
Assert.AreEqual(initialPosition.z, finalPosition.z); 


Este script está com tudo misturado: setup, asserts e ações, mas 
depois veremos como melhorar isso. O teste se chama 
PlayerMovesOnlyTowardsXDirection , pois nosso objetivo aqui é garantir 
que nosso personagem seja capaz de se mover somente no eixo x. 
Além disso, como já falamos antes, testes de PlayMode devem ser 
formados com a anotação [unityTest] e a função contendo o teste 
deve retornar um IEnumerator , que corresponde às ações de Updates 
que queremos. Outro ponto é que agora podemos adicionar o 
namespace using Nsubstitute; . Quanto à construção do Objeto 


cube : 


var cube = new GameObject().AddComponent<MoveController>(); 
cube. gameObject .AddComponent<Rigidbody>() ; 


var service = Substitute. For<IUnityService>(); 
service.GetDeltaTime().Returns(0.3f); 
service.GetInputAxis("Horizontal").Returns(1f); 


cube.speed = 1f; 
cube.service = service; 


Precisamos que cube Seja UM gameobject com duas características: 
um script movecontroller € UM Rigidbody , igual AO nosso player . Na 
primeira linha é exatamente isso o que fazemos: declaramos cube 
como UM new GameObject() e associamos a ele UM MoveController 
COM AddComponent<MoveController>() . Logo em seguida, associamos ao 
gameObject de cube um Rigidbody COM 

cube. gameObject.AddComponent<Rigidbody>() . 


O próximo passo é pensarmos em como vamos usar a variável 
IUnityService service de MoveController . É nesse ponto que o 
NSubstitute entra, pois ele nos permite fazer uma implementação 
controlada para nossos testes. Para isso, basta declarar que vamos 
utilizar um "substituto para a interface Iunityservice" através da 


linha var service = Substitute.For<IUnityService>();. 


Agora podemos adicionar comportamentos ao nosso substituto e 
faremos isso para os métodos GetDeltaTime € 


GetInputaxis("Horizontal") , definindo valores de retorno como 0.3f e 
If; respectivamente: service.GetDeltaTime().Returns(0.3f) @ 


service.GetInputAxis("Horizontal").Returns(1f) . 


Com isso pronto, podemos definir esse atributo dentro de cube, 
assim como o atributo speed , cujo valor reduziremos, pois o teste 
não exige que grandes distâncias sejam percorridas. 


Já podemos definir as ações que faremos e obter as medidas 
desejadas: 


Vector3 initialPosition = cube.transform. position; 
cube.service.GetInputAxis("Horizontal"); 


yield return new WaitForSeconds(0.25f); 
Vector3 finalPosition = cube.transform.position; 


Aqui definimos duas medidas: a primeira é initialPosition, que 
define a posição de cube antes de qualquer coisa, e a segunda é 
finalPosition , que define a posição de cube depois de todas as 
ações. 


Agora tomamos duas ações: 


1. Mover o cubo na direção horizontal ( x) com 
cube.service.GetInputAxis("Horizontal"); . 
2. Esperar que e.25f segundos de updates ocorram com yield 


return new WaitForSeconds(@.25f); . 


O ultimo passo é fazer os asserts que garantam o que queremos: 


Assert.That(finalPosition.x > initialPosition.x); 
Assert.AreEqual(initialPosition.z, finalPosition.z); 


O objetivo do primeiro assert é dizer que a posição em x de 
finalPosition é maior que a de initialPosition , enquanto o assert 
debaixo garante que a posição z não foi alterada. 


13.2 Melhorando os testes de situações limites 


Nossos testes em relação à movimentação estão bem limitados com 
os seguintes casos: 


1. Teste de integração garantindo que x aumenta e z não 
aumenta. 

2. Teste unitário garantindo que, se x e z são zero, a posição 
inicial não muda. 

3. Teste unitário garantindo que, se x > o, a nova posição terá x 
maior que zero. 

4. Teste unitário garantindo que, se x > e & z > e, a nova posição 
terá x e z maiores que zero. 


Assim, podemos criar um teste unitário que testa o caso de x == q 
&& z < o e um teste de integração que teste x < o && z < o. Não é 
perfeito, mas garante mais coisas. Iniciaremos adicionando o teste 
unitário: 

//TestMove.cs 

[Test] 


public void TestNewPositionHasChangedNegativelyOnZ() 


{ 
float x = Of; 
float z = -3f; 
Vector3 position = new Vector3(3f, 4f, 5f); 


Vector3 newPosition = moveController.CalculatePosition(position, x, Z); 


Assert.AreEqual(new Vector3(3f, 4f, 2f), newPosition); 
} 


E agora podemos concluir com ambas as direções sendo negativas: 


//PlayTestMoveController.cs 
[UnityTest] 
public IEnumerator PlayerMovesNegativelyOnXZDirections() 


{ 


var cube = new GameObject().AddComponent<MoveController>(); 


cube. gameObject.AddComponent<Rigidbody>() ; 


var service = Substitute. For<IUnityService>(); 
service.GetDeltaTime().Returns(0.3f); 
service.GetInputAxis("Horizontal").Returns(-1f); 
service.GetInputAxis("Vertical").Returns(-1f); 


cube.speed = 1f; 
cube.service = service; 


Vector3 initialPosition = cube.transform. position; 
cube. service.GetInputAxis ("Horizontal"); 
cube. service.GetInputAxis ("Vertical"); 


yield return new WaitForSeconds(@.25f) ; 
Vector3 finalPosition = cube.transform. position; 


Assert. That(finalPosition.x < initialPosition.x); 
Assert. That(finalPosition.z < initialPosition.z); 


} 


Além disso, podemos refatorar o código de testes para extrair as 
porções comuns aos testes, que são a criação do cubo e as 
associações de atributos como speed € service: 


using System.Collections; 
using NUnit.Framework ; 

using NSubstitute; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class PlayTestMoveController 


{ 


public MoveController cube; 
public IUnityService service; 


public void Setup() 
{ 


cube = new GameObject() .AddComponent<MoveController>(); 
cube. gameObject .AddComponent<Rigidbody>() ; 
cube.speed = 1f; 


service = Substitute. For<IUnityService>() ; 
service.GetDeltaTime().Returns(0.3f); 


[UnityTest] 
public IEnumerator PlayerMovesOnlyTowardsXDirection() 


{ 
Setup(); 


service.GetInputAxis("Horizontal").Returns(1f); 
cube.service = service; 


Vector3 initialPosition = cube.transform. position; 
cube. service.GetInputAxis ("Horizontal"); 


yield return new WaitForSeconds(0.25f); 
Vector3 finalPosition = cube.transform. position; 


Assert.That(finalPosition.x > initialPosition.x); 
Assert.AreEqual(initialPosition.z, finalPosition.z); 


[UnityTest ] 

public IEnumerator PlayerMovesNegativelyOnXZDirections() 

{ 
Setup(); 
service.GetInputAxis("Horizontal").Returns(-1f); 
service.GetInputAxis("Vertical").Returns(-1f); 


cube.speed = 1f; 
cube.service = service; 


Vector3 initialPosition = cube.transform. position; 
cube. service.GetInputAxis("Horizontal"); 


cube. service.GetInputAxis ("Vertical"); 


yield return new WaitForSeconds(@.25f) ; 


Vector3 finalPosition = cube.transform. position; 


Assert.That(finalPosition.x < initialPosition.x); 
Assert.That(finalPosition.z < initialPosition.z); 


} 
} 
} 


Neste capítulo, aprendemos como gerenciar inputs e transforma-los 
em movimento. Além disso, aprendemos como criar testes unitários 
e de PlayMode que nos permitiram iniciar um fluxo de TDD. No 

próximo capítulo, vamos começar a entender como podemos aplicar 
o fluxo de TDD para games utilizando lógicas de spawn de inimigos. 


CAPÍTULO 14 
Um cenário no qual inimigos aparecem ao nosso 
redor 


Agora vamos partir para uma estratégia de TDD de fato, em vez de 
transformar um código existente em algo testável. No momento, 
temos nosso ambiente de testes configurado e inputs testados. 
Nossa estratégia agora será fazer um inimigo, geralmente chamado 
de spawn, aparecer em uma região circular em volta do nosso 
personagem. 


Como primeira etapa, precisamos de uma função que retorne um 
vector) COM a posição do nosso inimigo dentro de uma região de 
raio r em torno da posição playerPosition de nosso personagem. 
Depois disso, vamos testar primeiramente o aparecimento dos 
inimigos para então testarmos se eles aparecem cada vez mais 
próximos do player com o passar do tempo. 


Vamos partir para os testes unitários do primeiro cenário e fazer 
com que eles nos garantam essas condições. Para evitar problemas 
de testar funções impuras, vou passar como argumento o ângulo no 
qual o personagem deve aparecer, chamado de randomangle . Nosso 
primeiro teste partirá de um playerPosition = Vector3.Zero, r=1 € 
randomAngle = O, por ser o caso mais simples de posição. Nosso 
primeiro teste ficará assim: 


using NUnit.Framework ; 
using UnityEngine; 
using UnityEngine.TestTools; 


namespace Tests 


{ 


public class TestEnemySpawner 


{ 


EnemySpawner enemySpawner ; 


[OneTimeSetUp] 
public void TestSetUp() 


{ 


enemySpawner = new GameObject().AddComponent<EnemySpawner>(); 


} 


[Test] 
public void TestEnemySpawnForZeroValues() 


{ 
float radius = 1f; 


float angle = Of; 


Vector3 enemyPosition = enemySpawner.GetPosition(Vector3.ZERO, 
radius, angle); 
Vector3 expected = new Vector3(1, 0,0); 


Assert.AreEqual(expected, enemyPosition) ; 


} 
} 
} 


A implementação desse teste é bastante simples, mas antes 
precisamos que ele compile somente com: 


using UnityEngine; 
using System.Collections; 


public class EnemySpawner : MonoBehaviour 


{ 
public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 
{ 
return Vector3.zero; 
} 
} 


Depois fazemos o teste passar com: 


using UnityEngine; 
using System.Collections; 


public class EnemySpawner : MonoBehaviour 


{ 
public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 
{ 
return new Vector3(1, ©, 0); 
} 
} 


Agora, veremos três testes que atuam nessa linha para evoluirmos 
nossa função de spawn : quando o raio é zero, quando o raio é maior 
que 1 e, depois, quando o raio é menor que zero. No último caso, 
vou considerar que devemos ignorar o sinal. Já para o raio igual a 
zero, considero que ele deve ser ignorado e retornar 1, mas vamos 
começar com radius > 1: 


[Test] 
public void TestEnemySpawnForLargeRadius() 


{ 
float radius = 3f; 


float angle = of; 


Vector3 enemyPosition = enemySpawner.GetPosition(Vector3.zero, radius, 
angle); 
Vector3 expected = new Vector3(3, ©, 0); 


Assert.AreEqual(expected, enemyPosition) ; 


} 


Esse é um teste bastante simples, vamos ver como fica a 
implementação: 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 


{ 


return new Vector3(1, ©, 0) * radius; 


} 


Agora quando o raio for menor que zero: 


[Test] 
public void TestEnemySpawnForNegativeRadius() 


{ 
float radius = -5f; 


float angle = Of; 


Vector3 enemyPosition = enemySpawner.GetPosition(Vector3.zero, radius, 
angle); 
Vector3 expected = new Vector3(5, ©, 0); 


Assert.AreEqual(expected, enemyPosition) ; 


} 
Mais uma implementação simples com mathf.abs() : 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 


{ 
return new Vector3(1, ©, 0) * Mathf.Abs(radius) ; 


} 
Agora, precisamos garantir que zero é substituído por 1: 


[Test] 
public void TestEnemySpawnForZeroRadius() 


{ 
float radius = Q; 
float angle = ef; 


Vector3 enemyPosition = enemySpawner.GetPosition(Vector3.zero, radius, 
angle); 
Vector3 expected = new Vector3(1, O, 0); 


Assert.AreEqual(expected, enemyPosition) ; 


} 


Uma implementação simples poderia ser a seguinte, mas tudo bem 
se você prefere utilizar if/else OU reassignar a variável nela 
mesma: 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 


{ 


float correctedRadius = radius.CompareTo(@f) == 0? 1: 
Mathf.Abs(radius); 
return new Vector3(1, ©, 0) * correctedRadius; 


} 


Nosso próximo teste consiste em mover O player para longe da 
posição Vector3.zero , começando por um vector3.one : 


[Test] 
public void TestEnemySpawnForPlayerPosisionOne() 


{ 


float radius = 4; 
float angle = ef; 
Vector3 playerPosition = Vector3.one; 


Vector3 enemyPosition = enemySpawner.GetPosition(playerPosition, radius, 
angle); 
Vector3 expected = new Vector3(5, 1, 1); 


Assert.AreEqual(expected, enemyPosition) ; 


} 
Para implementar isso, obtemos: 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 
{ 


float correctedRadius = radius.CompareTo(@f) == 0? 1: 
Mathf.Abs(radius); 
return playerPosition + (new Vector3(1, ©, 0) * correctedRadius) ; 


} 


Com o código que escrevemos até aqui, não temos nenhuma 
garantia de que o valor do radius -tal que ə < radius < 1 - não vá 
nos trazer problemas, assim, podemos criar um caso para garantir 
que radius = 0.5 retorne 1: 


[Test] 
public void TestEnemySpawnForRadiusSmallerThanOne() 


{ 


float radius = 0.5f; 
float angle = of; 
Vector3 playerPosition = Vector3.one; 


Vector3 enemyPosition = enemySpawner.GetPosition(playerPosition, radius, 
angle); 
Vector3 expected = new Vector3(2, 1, 1); 


Assert.AreEqual(expected, enemyPosition) ; 


} 
Assim, nossa solução muda um pouco: 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 


float correctedRadius = radius > -1f && radius < 1f ? 1: 
Mathf.Abs(radius); 
return playerPosition + (new Vector3(1, O, 0) * correctedRadius) ; 


} 
E se o vetor de player position nao for vector3.one ? 


[Test] 
public void TestEnemySpawnForPlayerPosisionVariable() 


{ 


float radius = 4; 
float angle = of; 
Vector3 playerPosition = new Vector3(3, 4, 6); 


Vector3 enemyPosition = enemySpawner.GetPosition(playerPosition, radius, 
angle); 
Vector3 expected = new Vector3(7, 4, 6); 


Assert.AreEqual(expected, enemyPosition) ; 


} 


O teste anterior parece um pouco irrelevante, pois nao faz nada 
falhar, porém pode ser um bom teste para trazer algo diferente como 


outro ângulo. Assim, vamos mudar o ângulo para 45 graus? 
(Corrigindo o nome e o interior do teste antecedente). 


[Test] 
public void TestEnemySpawnForPlayerPosisionVariableAndAngleVariable() 
{ 

float radius = 4; 

float angle = Mathf.PI / 4; 

Vector3 playerPosition = new Vector3(3, 4, 6); 


Vector3 enemyPosition = enemySpawner.GetPosition(playerPosition, radius, 
angle); 
Vector3 expected = new Vector3(5.8f, 4, 8.8f); 


Assert.AreEqual(expected.x, enemyPosition.x, @.1f, "Positions differ x", 
null); 

Assert.AreEqual(expected.y, enemyPosition.y, @.1f, "Positions differ y", 
null); 

Assert.AreEqual(expected.z, enemyPosition.z, @.1f, "Positions differ z", 
null); 


} 


Precisamos utilizar um delta de ə.ıf pois o valor de mathf.PI é 
dificil de testar precisamente. Para encontrarmos a solução para 
esses testes, basta utilizar mMathf.cos @ Mathf.sin: 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 
{ 

float correctedRadius = radius > -1f && radius < 1f ? 1: 
Mathf.Abs(radius) ; 

return playerPosition + 

(new Vector3(Mathf.Cos(randomAngle), @, Mathf.Sin(randomAngle)) * 

correctedRadius) ; 


} 


14.1 Fazendo inimigos aparecerem 


Ótimo! Temos a posição do nosso inimigo, mas precisamos verificar 
se ele existe na cena ao chamarmos a função spawn . Para isso, vou 
primeiro criar um Prefab chamado Enemy e colocá-lo na pasta 
Resources . E lembrando que seria interessante adicionar uma tag ao 
Prefab, criei a tag Enemy . A imagem a seguir mostra como idealizei 
nosso inimigo: 
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Figura 14.1: Nosso inimigo do ponto de vista visual (Uma bola vermelha) 


Agora criamos uma pasta chamada Resources e arrastamos Enemy 
da Hierarchy até ela: 


Assets > Resources 





Figura 14.2: Movendo Enemy para pasta Resources 


PREFAB 


O sistema de Prefabs da Unity permite que você crie, configure e 
armazene conjuntos de componentes, chamados de Gameobjects 
com todas suas propriedades padrões e componentes filho para 
serem reutilizados ao longo do desenvolvimento. Além disso, 
eles podem servir como templates para criação de novas 
instâncias em uma cena, tanto na criação do cenário quanto em 
runtime. 


Qualquer edição de um Prefab reflete automaticamente em 
todas suas instâncias, por isso, tome cuidado ao editar valores. 
Isso não significa que todas as instâncias de Prefabs precisam 
ser idênticas. É possível sobrescrever valores ou criar novos 
Prefabs com esses valores diferentes. 


Alguns exemplos: 


e Assets de ambiente - árvores e rochas sao bons exemplos. 
e Personagens não jogaveis, NPC. 
e Projéteis - balas de canhão ou flechas de arcos. 





Para testarmos O spawn , precisamos criar um novo script em 
PlaymodeTests € Criar um teste para nossa função de spawn. Além 
disso, vamos dizer que a cada dois segundos um novo inimigo 
aparece: 


//PlayTestSpawn.cs 

using System.Collections; 
using NUnit.Framework ; 

using NSubstitute; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class PlayTestSpawn 


public Object enemyPrefab; 
public EnemySpawner world; 
public GameObject cube; 


[OneTimeSetUp] 

public void Setup() 

{ 
enemyPrefab = Resources.Load("Enemy"); 
cube = new GameObject(); 
cube.transform.position = new Vector3(2, 4, 6); 


world = new GameObject().AddComponent<EnemySpawner>() ; 
world.spawnTime = 2f; 

world.radius = 2f; 

world.enemy = enemyPrefab as GameObject; 

world.player = cube; 


[UnityTest ] 
public IEnumerator SpawnsFirstEnemy() 


{ 
var enemysBefore = GameObject.FindGameObjectswWithTag("Enemy") ; 


yield return new WaitForSeconds(3); 
var enemysAfter = GameObject.FindGameObjectsWithTag("Enemy") ; 


Assert.That(enemysAfter.Length > enemysBefore.Length); 


} 


Para podermos rodar esse teste, precisamos adicionar algumas 
propriedades ao script EnemySpawner : 


public class EnemySpawner : MonoBehaviour 
{ 

public float spawnTime; 

public float radius; 

public GameObject enemy; 

public GameObject player; 
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Figura 14.3: Teste de EnemySpawner falhando 


Para o teste passar, precisamos criar uma função spawn que é 
chamada via update : 


//EnemySpawner.cs 
using UnityEngine; 
using System; 


public class EnemySpawner : MonoBehaviour 


{ 


public float spawnTime; 
public float radius; 
public GameObject enemy; 
public GameObject player; 


System.Random random; 


void Start() 
{ 


random = new System.Random() ; 


} 


void Update() 


{ 
Spawn() ; 


} 


public Vector3 GetPosition(Vector3 playerPosition, float radius, float 
randomAngle) 


{ 


float correctedRadius = radius > -1f && radius < 1f ? 1 : 
Mathf.Abs(radius); 
return playerPosition + 
(new Vector3(Mathf.Cos(randomAngle), @, Mathf.Sin(randomAngle)) * 
correctedRadius); 


} 


private void Spawn() 


{ 


var angle = random.Next(@, 8); 

Vector3 spawnPosition = GetPosition(player.transform.position, radius, 
angle); 

Instantiate(enemy, spawnPosition, Quaternion.identity); 


} 
} 


Utilizei a classe system.Random pela facilidade de substituir valores. O 
método spawn faz três coisas: 


1. Utiliza O system.Random.Next para obter um valor randômico entre 
@ O ~2PI. 

2. Obtém uma posição aleatória para fazer spawn . 

3. Instancia o Prefab de Enemy na posição spawnPosition . 


Agora queremos garantir que esse objeto instanciado, Enemy, 
apareça apenas a cada dois segundos. Isso quer dizer que no 
primeiro teste devemos ter somente um Prefab Enemy, assim, 
adicionamos Assert .AreEqual(enemysafter. Length, 1); ao teste que 
temos em PlayTestSpawn . Para isso, precisamos testar o tempo 
corrente contra spawnTime : 


public class EnemySpawner : MonoBehaviour 


{ 


public float spawnTime; 
float time; 


void Start() 
{ 


random = new System.Random(); 


time = 0; 


void Update() 
{ 


time += Time.deltaTime; 
if (time >= spawnTime) 
{ 

Spawn(); 


} 


Podemos criar um novo teste e garantir que a quantidade de 
Prefabs é igual ao tempo que esperamos. Se definirmos 11 
segundos, esperamos que cinco inimigos apareçam: 


[UnityTest] 
public IEnumerator SpawnsManyEnemies() 


{ 
yield return new WaitForSeconds(11); 
var enemysAfter = GameObject.FindGameObjectsWithTag(" Enemy"); 


Assert.That (enemysAfter.Length >= 5); 
} 


Note que utilizei >=. Isso se deve ao fato de a cena já conter um 
Prefab Enemy . Com isso, nossa solução muda somente no método 
Update para: 


void Update() 
{ 


time += Time.deltaTime; 
if (time >= spawnTime) 
{ 
Spawn(); 
time = Of; 
} 
} 


Para não termos conflitos entre os testes, vamos precisar 
implementar uma estratégia de destruição de objetos a cada teste. 
Por isso, mudei a anotação [oneTimesetup] para simplesmente 
[Setup] e adicionei uma função de TearDown : 


[ TearDown ] 
public void TearDown() 


{ 
GameObject.Destroy(world) ; 
GameObject.Destroy(cube) ; 
foreach (GameObject obj in GameObject.FindGameObjectswithTag("Enemy") ) 


{ 
GameObject.Destroy(obj); 


} 


Além disso, ao olharmos a imagem a seguir, percebemos que a 
quantidade de posições para nossos Prefabs surgirem é bastante 
limitada. Por isso, alterei a função que gera ângulos para: 





Figura 14.4: Inimigos em locais restritos 


var angle = Mathf.PI * random.Next(0, 8) / random.Next(1, 10); 





Figura 14.5: Inimigos com diferentes posições 


14.2 Inimigos se aproximam com o tempo 


O próximo passo, a meu ver, é criar uma função que faça o raio 
reduzir a cada vez que um inimigo surge. Assim, podemos definir 
um raio inicial e ir reduzindo a distância em que cada inimigo 
aparece até chegar a uma distância de módulo 1. Para isso, defini 
que a taxa de redução, ou passo, vai ser de 1f, mas caso você 
prefira, crie uma variável para conter o passo que diminui o valor do 
raio. Mudei o raio para 10 com world.radius = 19f; . Nossa lógica 
consiste em testar se a distância do inimigo 1 até o player é maior 
que a distância do inimigo 2 até o player e assim por diante. Um 
teste bastante simples: 


[UnityTest] 
public IEnumerator EnemiesApproachPlayer() 


{ 


yield return new WaitForSeconds(11); 
var enemysAfter = GameObject.FindGameObjectsWithTag(" Enemy"); 


float firstDistance = 
Vector3.Distance(enemysaAfter[0].transform.position, 
cube. transform. position); 

float secondDistance = 
Vector3.Distance(enemysAfter[1].transform. position, 
cube. transform. position); 

float thirdDistance = 
Vector3.Distance(enemysAfter[2].transform.position, 
cube. transform. position) ; 

float forthDistance = 
Vector3.Distance(enemysAfter[3].transform. position, 
cube. transform. position) ; 


Assert. That(firstDistance > secondDistance) ; 

Assert.That(secondDistance > thirdDistance) ; 

Assert. That(thirdDistance > forthDistance) ; 
} 


Para implementarmos isso, basta adicionarmos uma variável _step 
em EnemySpawner € reduzir seu valor a cada ciclo (cuidado ao utilizar 
floats, pois não temos muitas garantias de seu valor e, por isso, O 

“step deve ser grande o suficiente para haver diferenças no teste): 


public class EnemySpawner : MonoBehaviour 


{ 


public float radius; 


float _time; 
float _step = 1f; 


System.Random random; 


void Start() 
{ 


random = new System.Random(); 
“time = 0; 


} 


void Update() 
{ 


“time += Time.deltaTime; 
if (_time >= spawnTime) 


{ 
Spawn() ; 
if (radius > step + 1.1) 
{ radius -= _step; } 
“time = Of; 
} 
} 


} 


Tudo está passando! Nosso próximo passo consiste em interagir de 
alguma maneira com o mundo ao nosso redor. 


CAPÍTULO 15 
Criando um sistema de vida 


Neste momento do nosso jogo, conseguimos controlar nosso 
personagem e temos objetos ("inimigos") que aparecem em um 
círculo ao nosso redor no decorrer do tempo. Agora queremos que a 
cada colisão nosso personagem perca vida e que isso reflita na 
nossa UI. 


A primeira etapa será a criação do conceito de vida e, então, a 
perda de vida será ativada por uma função de dano. Além disso, 
queremos que essa perda reflita na UI. Para o primeiro caso, criei 
um arquivo de testes para a vida chamado TestLife , que será 
responsável pela lógica de gerenciamento de vida. 


namespace Tests 


{ 
public class TestLife 


{ 


LifeGauge cube; 


[OneTimeSetUp] 
public void Setup() 


{ 
cube = new GameObject().AddComponent<LifeGauge>(); 
cube.life = 100; 
cube.damage = 5; 


} 


[Test] 
public void TestLifeSimpleDamaged() 
{ 


Assert.AreEqual(100, cube.life); 


cube.Damaged(); 


Assert.AreEqual(95, cube.life); 


} 
} 
} 


O teste anterior verifica se depois de uma chamada de Damaged a 
vida diminuiu. Agora precisamos de um script chamado LifeGauge , 
com um método Damaged() @ dois atributos life e damage : 


using UnityEngine; 


public class LifeGauge : MonoBehaviour 


{ 
public int life; 
public int damage; 


public void Damaged() => life = 95; 
} 


Depois disso, criamos um método com várias chamadas a Damaged : 


[Test] 
public void TestLifeMultiDamage() 


{ 
Assert.AreEqual(100, cube.life); 


cube.Damaged(); 
cube.Damaged(); 
cube.Damaged(); 


Assert.AreEqual(85, cube.life); 
} 


A solução para esse teste seria simplesmente: 
public void Damaged() => life -= damage; 


Além disso, precisamos limpar uma estratégia de setup para cada 
teste, o que nos faz substituir O [oneTimesetup] por um simples 
[SetUp] . 


Agora precisamos garantir que a vida não será menor que zero, 
assim, vamos criar um teste que chame a função Damaged muitas 
vezes: 


[Test] 
public void TestLifeAlwaysGreaterOrEqualToZero() 


{ 
Assert.AreEqual(100, cube.life); 


for (int i = @; i < 30; i++) 
{ 
cube.Damaged(); 


Assert.That(cube.life == 0); 
} 


Esse teste verifica se, com múltiplas chamadas a Damaged , a vida 
não fica menor que zero. Correndo esses testes, claramente vemos 
que life será muito menor que zero, portanto devemos garantir 
que, Se life for zero, nada acontecerá: 


public void Damaged() 


{ 
if (life > 0) 
{ 
life -= damage; 
} 
} 


E se life não for divisível por damage ? Para isso, criamos um teste 
com este cenário: 


[Test] 
public void TestLifeAlwaysGreaterOrEqualToZeroForVariableDamage() 


{ 
cube.damage = 7; 
Assert.AreEqual(100, cube.life); 


for (int i = ð; i < 30; i++) 


{ 


cube.Damaged(); 


Assert.That(cube.life == 0); 
} 


Neste caso, basta adicionar um outro if que garanta que life 
nunca será menor que zero: 


public void Damaged() 


{ 
if (life > 0) 
{ 
life -= damage; 
} 
if (life <= 0) 
{ 
life = 0; 
} 


15.1 Testando danos na UI 


Agora precisamos garantir que, quando um inimigo colidir com o 
cubo, sua vida seja reduzida por damage e que isso reflita em uma 
barra de vida na UI. Para isso funcionar, precisamos que nosso 
script receba um componente scroll, que será nosso medidor de 
vida. 


Vamos criar um teste para indicar que, quando um inimigo colidir 
com nosso cube, diminua a vida do nosso cube visualmente no 
scroll . Nosso primeiro teste é para garantir que o valor de 1ifebar, 
variável que contém O scroll , seja iguala life de cube: 


//PlayTestLife.cs 
using System.Collections; 


using NUnit.Framework ; 

using NSubstitute; 

using UnityEngine; 

using UnityEngine.UI; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class PlayTestLife 


{ 
public LifeGauge cube; 


public Slider lifebar; 


[Setup] 
public void Setup() 


{ 
lifebar = new GameObject().AddComponent<Slider>(); 


lifebar.maxValue = 100; 

cube = new GameObject().AddComponent<LifeGauge>(); 
cube.lifebar = lifebar; 

cube.life = 91; 


[UnityTest] 
public IEnumerator StartsLife() 
{ 


yield return null; 


Assert.AreEqual(cube.life, cube.lifebar.value); 


} 
} 
} 


A ideia desse teste é termos um slider de vida cujo valor inicial é 
igual ao valor inicial de cube.1ife . Para resolvê-lo, basta a seguinte 
implementação: 


public class LifeGauge : MonoBehaviour 


{ 
public int life; 


public int damage; 
public Slider lifebar; 


void Start() 
{ 


lifebar.value = life; 


} 


Agora precisamos de um teste que diminua tanto a 1ifebar quanto a 
life quando há uma colisão. Infelizmente, para esse teste 
precisamos deixar o método oncollisionEnter público. Nosso objetivo 
é garantir que, com três colisões, a vida apresentada em 

cube.lifebar terá diminuído em nove unidades: 


//PlayTestLife.cs 

[SetUp] 

public void Setup() 

{ 
lifebar = new GameObject().AddComponent<Slider>(); 
lifebar.maxValue = 100; 


cube = new GameObject() .AddComponent<LifeGauge>() ; 
cube.lifebar = lifebar; 

cube.life = 91; 

cube.damage = 3; 


[UnityTest ] 

public IEnumerator ReducesLife() 

{ 
cube.OnCollisionEnter(new Collision()); 
yield return null; 


cube.OnCollisionEnter(new Collision()); 
yield return null; 


cube.OnCollisionEnter(new Collision()); 
yield return null; 


Assert.AreEqual(cube. life, cube.lifebar.value); 
Assert.AreEqual(82, cube.lifebar.value); 


Para resolver esse cenário, devemos implementar o seguinte: 


private void Update() 
{ 


lifebar.value = life; 


} 


public void OnCollisionEnter(Collision collision) => Damaged() ; 


Não se esqueça de adicionar na interface da Unity um slider dentro 
de um canvas e associar esse slider ao script LifeGauge NO NOSSO 
cubo. Do ponto de vista de jogabilidade é importante também 
adicionar colliders Nos limites do plano de jogo para que nosso 
player não caia. 


O último teste desta seção é adicionar o texto "você perdeu" quando 
lifebar.value for igual a Zero: 


[Setup] 
public void Setup() 


{ 
var text = new GameObject().AddComponent<Text>(); 


text.text = "OK"; 


cube.lose = text; 


[UnityTest ] 

public IEnumerator EnablesYouloseText() 

{ 
Assert.AreEqual(91, cube.lifebar.value); 
Assert.False(cube.lose.enabled); 


cube.lifebar.value = 0; 
yield return new WaitForFixedUpdate(); 


Assert.AreEqual("You lose", cube.lose.text); 
Assert.IsTrue(cube. lose. enabled) ; 


} 


Neste teste, queremos garantir que a vida inicial é 91 e que o campo 
de texto lose está desativado, mas logo depois de um update com a 
vida zerada, o campo de texto se torna ativo e com o valor de vou 
lose . À implementação é bastante simples: 


public class LifeGauge : MonoBehaviour 


{ 
public Text lose; 


void Start() { 
lifebar.value = life; 
lose.enabled = false; 
lose.text = "You lose"; 


} 


void Update() { 
lifebar.value = life; 
if (lifebar.value <= 0) 


{ 


lose.enabled = true; 


} 
} 
} 


Veja como, ao utilizar testes, nosso codigo adquiriu muitas garantias 
e, ao mesmo tempo, uma bela simplicidade. Segundo entusiastas 
do TDD, essa é uma das formas de diminuir bugs em produção e ter 
um código mais simples e legível. Não se esqueça de adicionar um 
campo de Text em canvas € associar esse campo a LifeGauge . 


Um exercício legal para fazermos antes de começar o próximo 
capítulo é fazer aparecerem itens de vida a cada x tempo para 
aumentar sua vida. Nosso próximo passo será deixar este jogo mais 
jogável, fazendo com que a câmera siga nosso personagem. 


CAPÍTULO 16 
Incluindo uma câmera e toques finais 


Fizemos muitas coisas até agora, detecção de interação com 
teclado, aparecimento de inimigos e gerenciamento de vida, mas 
ainda falta algo para nosso jogo ser efetivamente jogável. Se você 
tentar jogá-lo neste momento, perceberá que é muito difícil 
identificar a posição dos objetos, visto que o chão é totalmente 
branco e a câmera nunca se movimenta para acompanhar o 
personagem. Precisamos dar textura ao chão e fazer com que a 
câmera acompanhe nosso player . 


Para a câmera, vamos precisar definir uma configuração inicial e 
depois fazer com que ela atualize sua posição com a do jogador em 
movimento. Criaremos também uma forma de contar o tempo na UI 
e indicar qual a pontuação, em segundos, que o jogador atingiu. 
Precisamos também parar o jogo, uma vez que o player tenha 
morrido. E por último, o que são testes automatizados sem um bom 
CI? Portanto, vamos ver uma implementação de Cl para Unity. 
Assim, para a configuração da câmera vamos precisar de algo que 
explore o contraste da nossa posição atual com a anterior, o que 
podemos fazer adicionando uma imagem ao plano de base. 
Imagens no contexto de games costumam ser chamadas de sprites. 


Minha sugestão para a questão do chão é adicionar um sprite 
xadrez, que é fácil de encontrar na internet, e adicioná-lo como 
material ao chao. Para fazer isso, crie a pasta sprites em Assets , 
clique nela com o botão direito para dar Import new asset e escolha a 
imagem desejada. 
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Figura 16.1: Adicionando um sprite em nosso jogo 


Além disso, nao se esqueça de criar um novo material para colocar 
O sprite como base, clicando no círculo ao lado de Albedo . 
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Figura 16.2: Selecionando o sprite como Albedo 


A cara do nosso jogo até então: 





Figura 16.3: Como está nosso jogo 


16.1 A câmera 


A primeira coisa que precisamos garantir em um script de câmera é 
que a proximidade entre ela e a personagem se mantenha 
constante. A isso vamos chamar de offset e será um Vector3 , pois 
se trata de uma posição relativa. Essa variável poderia muito bem 
ser privada, mas quero garantir sua testabilidade sem grandes 
esforços, assim como dar a possibilidade de alteração para uma 
pessoa conforme ela achar melhor para seu jogo. Além de offset 
precisamos de um Transform de referência, ou seja, a posição do 
personagem, que chamarei de target . Um teste para offset precisa 


utilizar o método start . Para isso, vamos utilizar um teste de 
Playmode chamado PlayTestCamera.cs : 


using System.Collections; 

using System.Collections.Generic; 
using NUnit.Framework ; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 


public class PlayTestCamera 


{ 


MoveController moveController; 
CameraController camera; 


[SetUp] 
public void TestSetUp() 


{ 


moveController = new GameObject().AddComponent<MoveController>(); 
moveController.gameObject .AddComponent<Rigidbody>(); 
moveController.transform. position = Vector3.one; 


[UnityTest ] 
public IEnumerator OffsetIsCreatedAsStart() 
{ 


camera = new GameObject() .AddComponent<CameraController>(); 
camera.transform.position = new Vector3(3, 3, 3); 
camera.target = moveController.transform; 


yield return null; 


Assert. That(camera.Offset.x.CompareTo(2.0f) == 0); 


} 


Com nosso teste fazemos o seguinte: 


1. Definimos duas variáveis dos tipos movecontroller e 
CameraController . Não precisaríamos de Movecontroller por 
enquanto, pois bastaria um Gameobject COM Transform.position 
como target de CameraCcontroller , mas nos próximos testes 
precisaremos dele para mover a câmera. 

2. MoveController precisa de um script MoveController , UM 
Rigidbody € UMA position, então os definimos. 

3. Depois precisamos definir nossa variável camera como um script 

CameraController €e adicionar uma position à câmera. 

. Passamos O moveController.transform COMO target de camera. 

. COM yield return null garantimos que inicializamos um frame. 

. Garantimos que uma das variáveis de camera.offset mudou de 

valor de 2,0*. 


o of 


Para resolvermos esse fluxo de testes, basta definirmos offset no 
metodo start: 


using UnityEngine; 


public class CameraController : MonoBehaviour 


{ 


public Transform target; 
public Vector3 Offset { get; set; } 


void Start() 
{ 


Offset = transform.position - target.position; 


} 
} 


O próximo passo é verificarmos se em uma chamada de update na 
qual o MoveController varia de posição a camera varia junto. Para 
isso, precisamos fazer com que a IUnityService QUE MoveController 
possui seja implementada: 


using NUnit.Framework ; 
using NSubstitute; 


namespace Tests 


{ 


public class PlayTestCamera 


{ 


MoveController moveController; 
CameraController camera; 
IUnityService service; 


[SetUp] 

public void TestSetUp() 

{ 
moveController = new GameObject().AddComponent<MoveController>(); 
moveController .game0bject.AddComponent<Rigidbody>(); 
moveController.transform.position = Vector3.one; 


camera = new GameObject().AddComponent<CameraController>(); 
camera.transform.position = new Vector3(3, 3, 3); 
camera.target = moveController.transform; 


service = Substitute.For<IUnityService>(); 
service.GetDeltaTime().Returns(0.3f); 


[UnityTest ] 
public IEnumerator OffsetIsCreatedAsStart() 
{ 


yield return null; 


Assert. That(camera.Offset.x.CompareTo(2.@f) == 0); 
} 


[UnityTest] 
public IEnumerator CameraPositionIsGreaterWhenObjMovesRight() 


{ 


service.GetInputAxis("Horizontal").Returns(1f); 
moveController.service = service; 


Vector3 initialPosition = camera.transform.position; 


moveController.service.GetInputAxis("Horizontal"); 
yield return new WaitForSeconds(1f); 
Vector3 finalPosition = camera.transform.position; 


Assert.That(finalPosition.x > initialPosition.x); 
Assert.AreEqual(initialPosition.z, finalPosition.z); 


} 
} 
} 


Veja que o teste offsetIscreatedasstart foi simplificado, retirando as 
declarações de camera € movendo para [setup] . Além disso, o teste 
CameraPositionIsGreaterWhenobjMovesRight faz a medição da posição da 
camera antes e depois que 
moveController.service.GetInputAxis("Horizontal") é executado, O que 
nos permite fazer um assert em que z não variou, mas x variou. 
Dada a condição desse teste, nossa implementação em 
CameraController precisa, somente, redefinir a variável position.x de 
camera para o novo valor e manter iguais position.z € position.y. 


Agora adicionamos um teste para ela se mover verticalmente, mas 
desta vez apontei para valores negativos. E basicamente o mesmo 
teste mas com os valores de x e z se invertendo: 


[UnityTest] 
public IEnumerator CameraPositionIsGreaterWhenobjMovesUp() 


{ 


service.GetInputAxis("Vertical").Returns(-1f); 
moveController.service = service; 


Vector3 initialPosition = camera.transform. position; 
moveController.service.GetInputAxis ("Vertical"); 


yield return new WaitForSeconds(1f) ; 


Vector3 finalPosition = camera.transform. position; 


Assert.That(finalPosition.z < initialPosition.z); 
Assert.AreEqual(initialPosition.x, finalPosition.x); 


} 


Para esse teste funcionar, basta uma linha em update que redefina o 
valor de position para target.position + Ofset : 


void FixedUpdate() 
{ 


transform.position = target.position + Offset; 


} 


Um caso que podemos testar por garantia, mas que vai passar, é O 
caso de não haver movimento: 


[UnityTest] 
public IEnumerator CameraDoesntMoveIfPlayerDoesntMove() 


{ 


moveController.service = service; 

Vector3 initialPosition = camera.transform.position; 
yield return new WaitForSeconds(1f); 

Vector3 finalPosition = camera.transform.position; 


Assert.AreEqual(finalPosition.z, initialPosition.z); 
Assert.AreEqual(initialPosition.x, finalPosition.x); 


} 


Esse teste garante que, se nenhum comando de movimento for 
feito, não haverá diferença nas posições iniciais. Como pequena 
refatoração para essa função, podemos adicionar a função 
Vector3.Lerp , para que haja uma transição mais suave do ponto 
initialPosition até O ponto finalPosition : 


public class CameraController : MonoBehaviour 


{ 
public float smoothing = 10f; 


public Transform target; 


public Vector3 Offset ( get; set; } 


void FixedUpdate() 


{ 
Vector3 targetCam = target.position + Offset; 
transform.position = Vector3.Lerp(transform.position, targetCam, 
smoothing * Time.deltaTime); 


} 
} 


Todos os testes continuam passando. Agora podemos adicionar 
esse script a MainCamera e colocar player como propriedade target, 
conforme a imagem a seguir: 
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Figura 16.4: Incluindo CameraController em MainCamera 


16.2 Time Attack 


Geralmente, um jogo precisa de um certo grau de competitividade. 
Então, vamos utilizar uma estratégia para verificar quanto tempo do 
jogo se passou até a morte do player. Assim, precisamos testar se 


uma propriedade do nosso script aumenta x segundos para cada x 
segundos que passaram. Um teste simples seria: 


// PlayTestTimeAttack.cs 

using System.Collections; 

using System.Collections.Generic; 
using NUnit.Framework ; 

using UnityEngine; 

using UnityEngine.TestTools; 


namespace Tests 


{ 
public class PlayTestTimeAttack 


{ 


[UnityTest] 
public IEnumerator TimeAttackTakes5Secs() 


{ 
var time = new GameObject().AddComponent<TimeAttack>(); 


yield return new WaitForSeconds(5); 


Assert.AreEqual(5, Mathf.FloorToInt(time.timer)); 


} 
} 
} 


Note que utilizamos a função mathf.FloorToInt . Isso se deve ao fato 
de que somar Time.deltaTime durante cinco segundos deve 
ultrapassar os exatos cinco segundos que definimos em new 
WaitForseconds(5) , já que cada frame não demora um tempo exato. 
Para implementarmos isso, basta termos um campo associado a um 
timer e agregarmos Time.deltaTime EM cada Update : 


public class TimeAttack : MonoBehaviour 


{ 
public float timer; 


// Start is called before the first frame update 
void Start() 


{ 


timer = 0; 


} 


// Update is called once per frame 
void Update() 


{ 


timer += Time.deltaTime; 
} 
} 


Agora nosso novo teste verificará se o timer vai parar quando a vida 
for zero: 


public class PlayTestTimeAttack 
{ 

TimeAttack time; 

LifeGauge life; 


[SetUp] 

public void SetUp() 

{ 
time = new GameObject() .AddComponent<TimeAttack>(); 
life = new GameObject() .AddComponent<LifeGauge>() ; 
life.life = 100; 
life.lifebar = new GameObject().AddComponent<Slider>(); 
life.loose = new GameObject() .AddComponent<Text>(); 
time.lifeGauge = life; 


[UnityTest ] 
public IEnumerator TimeAttackTakes5Secs() 
{ 


yield return new WaitForSeconds(5); 


Assert.AreEqual(5, Mathf.FloorToInt(time.timer) ) ; 
} 


[UnityTest] 
public IEnumerator TimeAttackStopsWhenLifeIsZero() 
{ 


yield return new WaitForSeconds(4); 
Assert.AreEqual(4, Mathf.FloorToInt(time.timer)); 


var initialTimer = time.timer; 
life.life = 0; 


yield return new WaitForSeconds(5); 


var finalTimer = time.timer; 


Assert.AreEqual(initialTimer, finalTimer) ; 


} 
} 


Esse teste € um pouco mais complexo. Primeiro, ele garante que o 
timer aumentou em quatro segundos devido ao yield return new 
WaitForseconds(4) , COM isso, ele obtém a variável initialTimer , que é 
o resultado dessa interação. Ao setar a vida para zero, esperamos 
que o timer após x segundos não mude e, para isso, deixamos 
mais cinco segundos de jogo correrem. Obtemos a nova variável de 
timer e verificamos se finalTimer == initialTimer COM 
Assert.AreEqual(initialTimer, finalTimer);. A implementação disso 
nos exige que o script receba um LifeGauge , para medirmos o 
estado da variável life: 


public class TimeAttack : MonoBehaviour 
{ 

public float timer; 

public LifeGauge lifeGauge; 


// Update is called once per frame 
void Update() 
{ 

if (lifeGauge.life > 0) 

{ 


timer += Time.deltaTime; 


} 


} 
} 


Agora precisamos de uma garantia de que esse script vai atualizar o 
timer de um campo de texto no cenario. Entao, adicionei um campo 
de texto no canto superior direito do canvas com o texto Time Attack: 
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Figura 16.5: Adicionando Time Attack a um objeto de texto 


Com isso, vamos garantir que o objeto texto seja criado com o valor 
de Time Attack: 0.00: 


namespace Tests 


{ 


public class PlayTestTimeAttack 


{ 
TimeAttack time; 
LifeGauge life; 


[SetUp] 
public void SetUp() 


{ 
time = new GameObject().AddComponent<TimeAttack>(); 


life = new GameObject() .AddComponent<LifeGauge>() ; 
var text = new GameObject().AddComponent<Text>() ; 
text.text = "Time Attack: {0:F2}"; 

life.life = 100; 


time.lifeGauge = life; 
time.text = text; 


} 


[UnityTest ] 
public IEnumerator TimeAttackRendersTextwWith@value() 
{ 


yield return null; 


Assert.AreEqual("Time Attack: O", time.text.text.Split(' .' )[@]); 


} 
} 
} 


Para implementarmos esse teste devemos adicionar um campo 

Text ao script de Timeattack e referenciá-lo entre os componentes. 
Além disso, time.text.text.Split(' .' )[@] é usado para comparar 
somente o tempo em segundos, pois como não temos controle de 
Time.deltaTime é bastante provável que o tempo após a vírgula varie 
substancialmente de teste para teste. No caso, defini um campo no 
script do componente como public Text text e adicionei esse 
mesmo componente ao campo public Text text pelo editor (uma 
associação cíclica). Pode ser viável obtê-lo em start através de um 
GetComponent<Text>() , porém creio que isso dificulta a testabilidade: 


public class TimeAttack : MonoBehaviour 


{ 
public float timer; 


public LifeGauge lifeGauge; 
public Text text; 


// Start is called before the first frame update 
void Start() 
{ 


timer = 0; 
text.text = string.Format(text.text, timer); 


} 
} 


Necessitamos também que o campo string esteja atualizado de 
acordo com o tempo que passou. Por isso, criamos um novo teste 
que mede depois de x segundos: 


[UnityTest] 
public IEnumerator TimeAttackRendersTextWithIncreasingValues() 


{ 


yield return new WaitForSeconds(2); 
Assert.AreEqual("Time Attack: 2", time.text.text.Split(' .' )[Ə]); 
yield return new WaitForSeconds(4); 


Assert.AreEqual("Time Attack: 6", time.text.text.Split(' .' )[Ə]); 
} 


Nosso teste consiste em dois assert respectivos ao tempo 
decorrido, com a intenção de provar que há um aumento no valor de 
timer . A solução para esse teste é basicamente sobrescrever o 
valor de text.text . Além disso, extraí para uma constante FORMATTER 
o valor da string a ser formatada e defini o valor de float em duas 
casas decimais: 


public class TimeAttack : MonoBehaviour 


{ 


public Text text; 
const string FORMATTER = "Time Attack: (0:F2)"; 


void Start() 
{ 


timer = ð; 
text.text = string.Format(FORMATTER, timer) ; 


void Update() 


{ 
if (lifeGauge.life > 0) 


{ 


timer += Time.deltaTime; 


} 
text.text = string.Format(FORMATTER, timer); 


} 
} 


Tudo certo e funcionando, agora podemos ir para os últimos ajustes. 
Últimos passos 


Creio que os últimos passos sejam impedir que EnemySpawner 
continue gerando inimigos e que O player consiga se mexer depois 
que a vida chegar a zero. Para tanto, podemos criar uma função que 
retorne um booleano dizendo se o player ainda tem vida: 


[Test] 
public void TestIsAliveReturnsTrueWhenAlive() 


{ 
cube.life = 100; 
Assert.IsTrue(cube. IsAlive()); 


cube.life = 1; 


Assert.IsTrue(cube. IsAlive()); 
} 


Para isso, criamos a função Isalive assim: 


public bool IsAlive() 
{ 


return true; 


} 
O próximo teste é verificar se Isalive é falso para life igual a zero: 


[Test] 
public void TestIsAliveReturnsFalsewWhenDead() 


{ 
cube.life = ð; 


Assert. IsFalse(cube.IsAlive()); 
} 


Que resolvemos com: 


public bool IsAlive() 
{ 


return life > 0; 


} 


Temos outros testes que garantem que life não pode ser menor 
que zero, mas achei prudente utilizar o >. Agora podemos utilizar a 
função Isalive para bloquear o movimento de movecontroller e de 
EnemySpawner . Primeiro, começamos com o seguinte teste para 


EnemySpawner : 


namespace Tests 


{ 
public class PlayTestSpawn 


{ 
LifeGauge life; 


[OneTimeSetUp] 

public void OneTimeSetUp() 

{ 
life = new GameObject() .AddComponent<LifeGauge>() ; 
life.lifebar = new GameObject().AddComponent<Slider>(); 
life.loose = new GameObject().AddComponent<Text>(); 


[SetUp] 
public void Setup() 


{ 
world.lifeGauge = life; 


life.life = 100; 
} 


[UnityTest ] 
public IEnumerator SpawnsManyEnemiesUntilLifeIsZero() 


{ 


yield return new WaitForSeconds(3) ; 
var enemysAfter = GameObject.FindGameObjectsWithTag("Enemy") ; 


Assert.That(enemysAfter.Length >= 1); 


life.life = 0; 
yield return new WaitForSeconds(3); 


var enemysLifeZero = GameObject.FindGameObjectsWithTag(" Enemy"); 


Assert.AreEqual(enemysAfter.Length, enemysLifeZero. Length); 


} 
} 
} 


Esse teste faz o seguinte: com a vida maior que zero, ele cria alguns 
objetos, que sabemos ser mais que um atraves do 

Assert. That(enemysAfter.Length >= 1). Depois disso, zeramos a vida 
com life.life = é e verificamos que após 3 segundos a quantidade 
de inimigos é a mesma. Para resolver isso, precisamos de um 
LifeGauge EM EnemySpawner , € utilizar a função Isalive para garantir 
que o player está com vida: 


public class EnemySpawner : MonoBehaviour 


public LifeGauge lifeGauge; 


void Update() 

{ 
_time += Time.deltaTime; 
if (_time >= spawnTime && lifeGauge.IsAlive()) 
{ 


} 


Não se esqueça de relacionar esses componentes na interface da 
Unity. Agora precisamos do mesmo tipo de teste para 
MoveController . Os testes serão bastante parecidos: 


using System.Collections; 
using NUnit.Framework; 

using NSubstitute; 

using UnityEngine; 

using UnityEngine.UI; 

using UnityEngine.TestTools; 


namespace Tests 
{ 
public class PlayTestMoveController 
{ 
public MoveController cube; 
public IUnityService service; 
LifeGauge life; 


[OneTimeSetUp] 
public void OneTimeSetUp() 


{ 
life = new GameObject() .AddComponent<LifeGauge>() ; 
life.lifebar = new GameObject().AddComponent<Slider>(); 
life.loose = new GameObject().AddComponent<Text>(); 


public void Setup() 


life.life = 100; 
cube. lifeGauge = life; 


} 


[UnityTest ] 
public IEnumerator PlayerStopsMovingWhenLifelIsZero() 


{ 
Setup(); 
service.GetInputAxis("Horizontal").Returns(-1Ff); 
service.GetInputAxis("Vertical").Returns(-1f); 


cube.speed = 1f; 
cube.service = service; 


Vector3 initialPosition = cube.transform. position; 
life.life = 0; 


cube.service.GetInputAxis("Horizontal"); 
cube.service.GetInputAxis("Vertical"); 


yield return new WaitForSeconds(0.25f); 
Vector3 finalPosition = cube.transform. position; 


Assert.AreEqual(initialPosition.x, finalPosition.x); 
Assert.AreEqual(initialPosition.z, finalPosition.z); 


} 


Agora, para esse teste passar, precisamos da mesma estratégia que 
Usamos em EnemySpawner : 


using System.Collections; 
using System.Collections.Generic; 
using UnityEngine; 


public class MoveController : MonoBehaviour 


{ 


public LifeGauge lifeGauge; 


void Update() 


{ 
if (lifeGauge.IsAlive() ) 
{ 
_rb.MovePosition(CalculatePosition(transform.position, x, z)); 
} 
} 


} 


Novamente, devemos associar LifeGauge à EnemySpawner ea 
MoveController , Mas percebemos QUE EnemySpawner já possui um 
atributo chamado player : 
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Figura 16.6: EnemySpawner com atributos repetidos 


Com isso, vemos uma boa oportunidade para refatorar. Então, as 
seguintes mudanças foram feitas nos testes: 


namespace Tests 
{ 
public class PlayTestSpawn 
{ 
Object enemyPrefab; 
EnemySpawner world; 
LifeGauge life; 


[OneTimeSetUp] 
public void OneTimeSetUp() 


{ 
life = new GameObject() .AddComponent<LifeGauge>() ; 
life.lifebar = new GameObject().AddComponent<Slider>(); 
life.loose = new GameObject().AddComponent<Text>(); 

} 

[SetUp] 

public void Setup() 

{ 
enemyPrefab = Resources.Load("Enemy"); 
world = new GameObject().AddComponent<EnemySpawner>() ; 
world.spawnTime = 2f; 
world.radius = 10f; 
world.enemy = enemyPrefab as GameObject; 
world.lifeGauge = life; 
life.transform.position = new Vector3(2, 4, 6); 
life.life = 100; 

} 

[TearDown] 

public void TearDown() 

{ 


GameObject.Destroy(world); 
foreach (GameObject obj in 
GameObject . FindGameObjectsWithTag("Enemy")) 


{ 
GameObject.Destroy(obj); 


[UnityTest ] 

public IEnumerator SpawnsFirstEnemy() 

{ 
var enemysBefore = GameObject.FindGameObjectsWithTag( "Enemy" ) ; 
yield return new WaitForSeconds(3); 
var enemysAfter = GameObject.FindGameObjectsWithTag("Enemy") ; 


Assert.That(enemysAfter.Length > enemysBefore.Length); 
Assert.AreEqual(enemysAfter.Length, 1); 


} 


[UnityTest ] 
public IEnumerator SpawnsManyEnemies() 
{ 
yield return new WaitForSeconds(11); 
var enemysAfter = GameObject.FindGameObjectsWithTag(" Enemy"); 


Assert.That(enemysAfter.Length >= 5); 
} 


[UnityTest ] 
public IEnumerator EnemiesApproachPlayer() 
{ 
yield return new WaitForSeconds(11) ; 
var enemysAfter = GameObject.FindGameObjectsWithTag("Enemy") ; 


float firstDistance = 
Vector3.Distance(enemysAfter[0@].transform. position, 
life.transform. position) ; 

float secondDistance = 
Vector3.Distance(enemysAfter[1].transform. position, 
life.transform. position) ; 

float thirdDistance = 
Vector3.Distance(enemysAfter[2].transform.position, 
life.transform. position) ; 

float forthDistance = 
Vector3.Distance(enemysAfter[3].transform. position, 
life.transform. position) ; 


Assert.That(firstDistance > secondDistance) ; 
Assert.That(secondDistance > thirdDistance) ; 
Assert.That(thirdDistance > forthDistance); 


[UnityTest] 
public IEnumerator SpawnsManyEnemiesUntilLifeIsZero() 


{ 


yield return new WaitForSeconds(3); 
var enemysAfter = GameObject.FindGameObjectsWithTag(" Enemy"); 


Assert.That(enemysAfter.Length >= 1); 


life.life = 0; 
yield return new WaitForSeconds(3); 


var enemysLifeZero = GameObject.FindGameObjectsWithTag(" Enemy"); 


Assert.AreEqual(enemysAfter.Length, enemysLifeZero. Length); 


} 
O que impacta nas seguintes mudanças em EnemySpawner : 


public class EnemySpawner : MonoBehaviour 
{ 

public float spawnTime; 

public float radius; 

public GameObject enemy; 

public LifeGauge lifeGauge; 

float _time; 

float step = 1f; 


public void Spawn() 
{ 
var angle = Mathf.PI * random.Next(@, 8) / random.Next(1, 10); 
Vector3 spawnPosition = GetPosition(lifeGauge.transform.position, 
radius, angle); 
Instantiate(enemy, spawnPosition, Quaternion.identity) ; 
} 
} 


Agora, o teste de PlayTestCamera precisa ser corrigido, pois ele 
recebe um objeto movecontroller : 


namespace Tests 


{ 
public class PlayTestCamera 
{ 
MoveController moveController; 
CameraController camera; 
IUnityService service; 
LifeGauge life; 
[SetUp] 
public void TestSetUp() 
{ 
life = new GameObject().AddComponent<LifeGauge>(); 
life.lifebar = new GameObject().AddComponent<Slider>(); 
life.loose = new GameObject().AddComponent<Text>(); 
life.life = 100; 
moveController = new GameObject() .AddComponent<MoveController>(); 
moveController.lifeGauge = life; 
} 
} 
} 


Embora nosso jogo já esteja pronto para ser jogado, do ponto de 
vista de desenvolvimento em times, ainda precisamos adicionar 

algumas coisas, como Cl para executar nossos testes. Veremos 

como fazer isso no próximo capítulo. 


CAPÍTULO 17 
Adicionando um Cl 


No livro Lean Game Development introduzimos o conceito de TDD 
para games. Seguindo a mesma linha, o conceito de Cls para o 
desenvolvimento de games foi apresentado. Ele tem como objetivos 
encontrar bugs o quanto antes, fazer versionamento do código, 
executar os testes e fazer deploy dos executáveis. Outra informação 
importante apresentada é que a execução do Cl deve ocorrer 
frequentemente ou pelo menos a cada vez que o código é integrado. 
Por último, ele facilita a disponibilização de versões alfas e betas 
para teste em hotlinks, stores ou cloud. 


17.1 Cl para Unity 


Criar um Cl para executar programas desenvolvidos na Unity é um 
pouco complicado, pois a Unity presta um serviço parecido, mas 
incompleto, e cobra por ele. Felizmente todas as informações 
relevantes para executar a linha de comando da Unity estão 
disponíveis em: 


https://docs.unity3d.com/Manual/CommandLineArguments.html. 


Escolhi como ferramenta de Cl o Travis Cl, devido à facilidade de 
adesão. Para iniciarmos o nosso Travis Cl, basta criarmos um 
arquivo .travis.yaml na raiz do projeto. O arquivo que criamos tem o 
seguinte formato, lembrando que estou utilizando um MacOS: 


#.travis.yaml 
language: objective-c 
osx image: xcode11 
rvm: 

- 2.2 

before_install: 


- chmod a+x ./Scripts/install.sh 
- chmod a+x ./Scripts/build.sh 
- chmod a+x ./Scripts/unit.sh 
- chmod a+x ./Scripts/integration.sh 
install: 
- ./Scripts/install.sh 
jobs: 
include: 
- stage: unit 
script: ./Scripts/unit.sh 
- stage: integration 
script: ./Scripts/integration.sh 
- stage: build 
script: ./Scripts/build.sh 


No campo before install damos as autorizações necessárias para 
correr os scripts. Em install instalamos a versão da Unity que 
estamos utilizando e em script rodamos os testes e o build. Note 
que possuímos uma nova pasta chamada scripts, com quatro 
arquivos: 


install.sh 


Parte da dificuldade da Unity com Travis é a utilização da Unity 
dentro da plataforma. Para isso, precisamos do endereço na Unity 
do UnityEditor . A url para obter o editor pode ser encontrada em 
https://netstorage.unity3d.com/unity/<Hash>/<Versão> , Mas para 
obtermos a Hash, podemos entrar na página https://unity3d.com/get- 
unity/download/archive. Escolha a versão e o sistema operacional 
de que você precisa e, com isso, escolha unityEditor . AS imagens a 
seguir mostram o que eu fiz: 
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Figura 17.1: Acessando o Unity Editor 
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Figura 17.2: Inspecionando a resposta de Network para o Unity Editor, uma possivel hash 
esta destacada 


Para mais informações sobre O install.sh : 
https://docs.unity3d.com/Manual/InstallingUnity.html. 


#! /bin/sh 


BASE URL=http://netstorage.unity3d.com/unity 
HASH=<Sua Hash> 
VERSION=2018.3.12f1 


download() { 
file=$1 
url="$BASE_URL/$HASH/$package" 
echo "Downloading from $url: " 

curl -o ~basename "$package"” "$url" 


install() { 
package=$1 


download "$package" 


echo "Installing "~basename "$package"” 
sudo installer -dumplog -package ~basename "$package"` -target / 


} 


install "MacEditorInstaller/Unity. pkg" 
install "MacEditorTargetInstaller/UnitySetup-Mac-Support -for- 
Editor-$VERSION. pkg" 


No script anterior, definimos três variáveis: a Base URL que define a 
URL na qual podemos fazer curl, a HasH conforme o que 
encontramos na imagem anterior, e vERSION, que corresponde a 
versão que queremos da Unity. A função download executa O curl 
do package que queremos. A função install chama a função 
download e executa o installer conforme o link anterior. 


unit.sh 


Nosso objetivo aqui é rodar todos os testes unitários, ou seja, os 
testes de EditMode . Para isso, criamos um script que chama o 
executor da Unity, que estará localizado em 
/Applications/Unity/Unity.app/Contents/MacOS/Unity para MacOS. No 
link de linha de comando podemos encontrar a localização para 
Windows. 


#!/bin/sh 
export EVENT_NOKQUEUE=1 


unity=' /Applications/Unity/Unity.app/Contents/MacOS/Unity 


echo "Start running Unity unit tests..." 

gunity -batchmode \ 
-projectPath "$(pwd)/" \ 
-runTests À 
-logFile "$(pwd)/output/editmode_log.xml" À 
-testResults "$(pwd)/output/editmode results.xml" À 
-testPlatform "editmode" 

result=$? 


if [ $result -ne O ]; then 
echo "Unity unit tests failed." 


exit $result 
fi 


Para nosso script, vamos entender quais sao os argumentos que 
aparecem: 


e -batchmode : Serve para eliminar janelas de pop-up e eliminar a 
necessidade de intervenção humana. 

e -projectPath : Serve para dizer onde o código estará localizado. 

e -runTests : indica que é para correr todos os testes. No caso, 
determinamos a plataforma de testes no item testPlatform. 

e -logFile : define onde devem ficar os logs gerados ao executar 
o comando. 

e -testResults : define onde devem ficar os resultados dos testes. 

e -testPlatform : define a plataforma na qual queremos correr os 
testes. Atualmente as opções são editmode (unitários) e 
playmode (integração). 


Além disso, a parte final do script é: 


result=$? 

if [ $result -ne O ]; then 
echo "Unity unit tests failed." 
exit $result 

fi 


Assim, esse bloco do script vai buscar o último valor de retorno da 
execução e verificar se é igual a zero. Se o valor de retorno não for 
igual a zero, receberemos um alerta de falha e o script parará. 


integration.sh 


É basicamente igual ao unit.sh, porém mudamos O editmode para 
playmode : 


#!/bin/sh 
export EVENT_NOKQUEUE=1 


unity=' /Applications/Unity/Unity.app/Contents/MacOS/Unity' 


echo "Start running Unity integration tests..." 
gunity -batchmode \ 
-projectPath "$(pwd)/" \ 
-runTests À 
-logFile "$(pwd)/output/playmode_log.xml" À 
-testResults "$(pwd)/output/playmode results.xml" À 
-testPlatform "playmode" 
result=$? 
if [ $result -ne O ]; then 
echo "Unity integration tests failed." 
exit $result 
fi 


build.sh 


Agora a última parte de nosso CI. A grande diferença aqui é que 
obviamente não vamos executar o comando -runTest , mas sim um 
comando de build. Este comando é O buildosxuniversalPlayer , para 
MacOS. Executar um build em outras plataformas é possível, mas é 
preciso adicionar as linhas a seguir NO install.sh: 


install "MacEditorTargetInstaller/UnitySetup-Windows-Support-for- 
Editor-$VERSION. pkg" 

install "MacEditorTargetInstaller/UnitySetup-Linux-Support-for- 
Editor-$VERSION. pkg" 


Eo bui ldoSXUniversalPlayer vira buildWindowsPlayer OU 
buildLinuxUniversalPlayer , então lembre-se de diferenciar as pastas 
para cada um. Assim, nosso script fica: 


#!/bin/sh 
export EVENT NOKQUEUE=1 


unity=' /Applications/Unity/Unity.app/Contents/MacOS/Unity' 


echo "Start building the project..." 
gunity -batchmode \ 


-nographics \ 

-projectPath "$(pwd)/src" À 

-logFile "$(pwd)/output/build_log.xml" À 
-buildOSXUniversalPlayer "$(pwd)/build/build.app" À 
-quit 


O maior problema que tive com esse Cl foi com a versao de 
download da Unity. Minha Hash original retornava uma versao 


2018.2 , que fazia com que os testes nao passassem. 
Procurando por hashes mais novas encontrei uma compativel. 





Com isso, nosso jogo esta pronto e possuimos uma forma concreta 
de desenvolver jogos via TDD com praticas de continuous 
integration. Note que no mundo de games nem tudo é 100% 
passivel de testes com frameworks simples, pois muitos testes 
exigem recursos como fotos e videos de gameplay para testar 
aspectos de cenário. Testes com videos são viáveis, mas não sao 
totalmente automatizáveis, pois no momento em que mudamos as 
artes ou criamos um cenário novo, alguém precisa avaliar se o vídeo 
está ou não de acordo com o esperado. 


Além disso, algumas sugestões de desafios para você continuar são 
diminuir O spawnTime e aumentar um pouco o raio no qual os inimigos 
surgem, para talvez aumentar as chances de sobrevivência. Para 
dar uma pequena chance de sobreviver por alguns segundos utilizei 
0.2f de spawnTime € raio de 5. 


Agora cabe a vocé jogar e se divertir para encontrar bugs e 
melhorar nosso codigo. Pull requests sao bem-vindos. 
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